SIP Options Ping
Cisco CME to Cisco UBE Options ping no-worky....
Did anyone get SIP options pings working on a pure Cisco router (UBE to UBE and UBE to CME) environment? I have a pure Cisco 15.1 network that we are playing with option pings on. I see pings go out and 200 OK responses, but dial-peers are still busying out. Have tried both default and example settings from Cisco UBE deployment guides. Routers are working with options pings from external ITSPs, so know options replies are working and are supported. So, what's the magic sauce on Cisco IOS 15.1 for SIP options-keepalive?
dial-peer voice 40221 voip
corlist outgoing peer-internal
description \\\ 4385 - 4389 \\\
translation-profile outgoing ToCUCME_NANP_PrefixedE164
preference 1
destination-pattern 438[5-9]
session protocol sipv2
session target ipv4:10.5.5.1
voice-class sip early-offer forced
voice-class sip options-keepalive up-interval 12 down-interval 65 retry 3
dtmf-relay rtp-nte
fax-relay ecm disable
no fax-relay sg3-to-g3
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-throug
no vad
There are no firewalls or NAT between and when using "debug ccsip message" we see option sent and received and replies on both sides.
Similar Messages
-
Best way to implement SIP Options Pings on a SIP Trunk
I wanted to see if anyone had suggestions on the best way to configure SIP Options Pings.
Typically I would configure them per dial-peer. However, I really want to do it per destination IP address. I do not want a SIP Options ping for every single dial-peer being sent out every X seconds.
Example:
In my case I have 4 SIP trunks in the same CUBE. Each pointing to a different destination IP. There are 6 dial-peers per SIP trunk. I really do not want 24 option pings going out every X seconds. I guess I've never actually did a debug to see how many pings are going out at a time but I am assuming it sends one for each dial-peer or does it?
If I am correct in my assumption, is there way to only send one ping per destination IP and if that single IP goes unresponsive then all 6 dial-peers go down?Hello,
The OOD option ping is sent per dial-peer to the destination.
Restrictions
•The Cisco Unified Border Element OOD Options ping feature can only be configured at the VoIP Dial-peer level.
•All dial peers start in an active (not busied out) state on a router boot or reboot.
•If a dial-peer has both an outbound proxy and a session target configured, the OOD options ping is sent to the outbound proxy address first.
•Though multiple dial-peers may point to the same SIP server IP address, an independent OOD options ping is sent for each dial-peer.
•If a SIP server is configured as a DNS hostname, OOD Options pings are sent to all the returned addresses until a response is received.
•Configuration for Cisco Unified Border Element OOD and TDM Gateway OOD are different, but can co-exist.
//Suresh
Please rate all the useful posts. -
Voice gateway, SIP Options ping without SDP
Hi all.
I see following SIP options call-flow for sip options ping:
17907581: Jan 16 08:11:31.057: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:10.250.20.25:5060 SIP/2.0
Via: SIP/2.0/UDP 10.11.3.17:9256;branch=z9hG4bKabuf3p5e3es57i595u9viaf77
Call-ID: [email protected]
From: <sip:[email protected]>;tag=sbc0800uf7upc43
To: <sip:10.250.20.25>
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0
17907583: Jan 16 08:11:31.057: //28111388/1CCF073F9ED3/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.11.3.17:9256;branch=z9hG4bKabuf3p5e3es57i595u9viaf77
From: <sip:[email protected]>;tag=sbc0800uf7upc43
To: <sip:10.250.20.25>;tag=BC08FBDC-1F16
Date: Fri, 16 Jan 2015 08:11:31 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-15.4.20141104.060737.
CSeq: 1 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 363
v=0
o=CiscoSystemsSIP-GW-UserAgent 1616 9170 IN IP4 10.13.4.43
s=SIP Call
c=IN IP4 10.13.4.43
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 10.13.4.43
m=image 0 udptl t38
c=IN IP4 10.13.4.43
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy
I know that this is normal behavior for voice gateway(3925 in our case).
Is it possible to disable SDP in 200 OK message going out to ITSP. They said that their PBX can't recognize 200 ok with SDP as reply to sip Options message.Oleh,
I am not sure you can do this..
RFC3261 states the following:
The SIP method OPTIONS allows a UA to query another UA or a proxy
server as to its capabilities. This allows a client to discover
information about the supported methods, content types, extensions,
codecs, etc. without "ringing" the other party. For example, before
a client inserts a Require header field into an INVITE listing an
option that it is not certain the destination UAS supports, the
client can query the destination UAS with an OPTIONS to see if this
option is returned in a Supported header field. All UAs MUST support
the OPTIONS method.
If the response to an OPTIONS is generated by a proxy server, the
proxy returns a 200 (OK), listing the capabilities of the server.
The response does not contain a message body.
So it looks like your ITSP hasn't designed their system based on this RFC. When you send an OPTIONs message, the response has to include the capabilities the other party can support.. -
SIP Options PING (CVP SIP Server Groups - Heartbeat)
The CVP Operations Console has a feature to enable SIP ping Options.
If you configure a SIP server group and enable heartbeats, the CVP Call Server sends a SIP ping option ever X seconds.
We have a SIP Server group for the CUCM servers and a group for the VXML Gateways.
The Cisco CUCM replies with a SIP 200 OK to these SIP 'ping' Options.
However the VXML Gateway does not. Does anyone know why not and if its possible to enable a gateway to reply to these SIP options?
Below is documentation on how to configure the Cisco Gateway to SEND ping options, but we don't that. We just need it to reply to the Ping OPTIONS sent by CVP.
For calls that originate from CUCM to CVP, they need to use the VXML Gateway SIP server group, (as it cannot route to the originator for VXML treatment).
http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/vb_book/vb_book/vb_9321.html
See screen shot where you can see replies from the CUCM servers (.200, .201) but NOT from VXML Gateway (.250).
Regards,
GerryHello Gerry,
You may need to enable the SIP Traces in the voice Gateway and have a look how exactly gateway is processing and why 200 OK is not sent.
Can you share the IOS Version on the Gateway ?
Look at the below link and list of Resolved Caveats in 15.2(4)M, one of the caveat looks like your scenario. But i would recommend first look into Sip traces.
http://www.cisco.com/c/en/us/td/docs/ios/15_2m_and_t/release/notes/15_2m_and_t/152-4MCAVS.html
CSCtx79318
Symptoms: OGW fails to send 200 OK response for OPTION.
Conditions: The symptom is observed with 200 OK response for OPTION in Cisco IOS interim Release 15.2(02.16)T.
Workaround: There is no workaround.
Regards,
Senthil -
Hi -
I have a strange problem and I'm looking for ideas. I have a version 9.1.2 CUCM cluster with two nodes. I am setting up two SIP trunks to our CUSP and in CUSP I have configured the CAC to send an Options ping to each CM server. The subscriber is sending a 200 OK reply to the Options ping but the publisher is not.
I set up a packet capture on both servers and I can see the Options ping coming into both. I see the 200 OK from the subscriber but the publisher does not reply. Also, in the RTMT CM logs I can see the Options ping on the subscriber but the publisher log does not show any SIP requests.
These are both HP servers - not VM
I'm unclear on what services or profiles etc. might be missing or misconfiguration of one server over another. I have restarted the publisher as well as all SIP trunks and SIP profiles.
Thanks,
LesI attached the RTMT output. You will see that there are no SIP messages in this log. I also took a screen shot of the wireshark output from the CLI packet capture. If you look in the RTMT log for the corresponding time (the wireshark is EDT and the RTMT is CDT so RTMT is an hour difference) you will see that there are no messages (15:34:14:613 or 14:34:14:613 in RTMT). I also grabbed a screen shot of the wireshark for the subscriber - you can see the 200 OK reply.
Regards,
Les
Publisher - wireshark output -
ISR 3945 - SNMP trap set up to recieve option pings from ASR1006
I am working on a set up : ISR 3945 - Receiving option pings from another device (ASR) and sending a snmp trap (say ex: if a link down on a dial-peer ) to snmp server if those option ping fails.
- Need inputs on SNMP config
Thanks in advance.Hi.
the easiest way is to get the snmp-server trap source command to work.
when you say it's not working, do you mean the branches still use the external interface as the source? or that it's sourced properly from vlan1 but somehow doesn't get encrypted?
what ios version are you running on the branches? maybe this is a bug and newer versions get it to work?
if you want to through another way than snmp-server trap source, then an ipsec redesign might be needed. As you noticed dmvpn would be the easiest. another solution would be dynamic lan-to-lan from branch to headend with gre tunnels (similar to dmvpn), and then force the route to the management network via GRE, this way the snmp trap source would default to use the tunnel ip address.
Regards,
Fadi. -
Why is E61i SIP client pinging strange IPs?
I reflashed my E61i (using NOKIA's software updater). Then installed Trend Micro's Web Security and set the firewall to high (disallowing outgoing packets except those specifically allowed eg http)
Wait a day. Check firewall logs and they're clean.
Install Handy Clock.
Wait another day, check firewall logs and they're clean.
Change firewall settings to allow SIP client to connect to SIP provider only. Setup SIP client for my VOIP provider.
E61i starts pinging IPs in china, spain, argentina, India, UK, Comcast etc at random intervals, sometimes as short as 2 minutes. Some of the IPs appear to be ADSL IPs.
Anyone has any explanation why NOKIA's SIP client should be pinging all these IPs? Is there a vulnerability in the SIP client?
Can anyone recommend a firewall which can tell you which process or application is trying to connect to the internet?
DonPlease find :
C:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . : srhouse.com
IPv4 Address. . . . . . . . . . . : 172.21.155.24
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.21.155.1
C:\> -
CUCM 10.5 - Order of trunks in Route Group ignored...Not sure why
Question #1
I've had a voice mail pilot number working for a long time now. It's MS Unified Messaging (MS UM for short). Since we have more than one MS UM server, I thought I'd go ahead and create a SIP trunk for each of the MS UM servers and then put them in the existing Route Group (RG). I thought I'd go ahead and reorder the trunk groups listed in the RG just to be sure my configure for the new trunk groups was correct. I have the SIP Options Ping enabled in my SIP profile and I do see all the MS UM SIP trunks with a status of 'Full Service'. Anyway, if I place one of the newly added SIP trunks for MS UM at the top of the existing RG, my calls are still ending up at the original MS UM server. It's like CUCM is ignoring the fact that I placed the new SIP trunk at the top and it keeps routing to the old/existing SIP trunks/MS UM server I had in this RG. I tried resetting the SIP trunks and also reset the Route List (which I didn't think I'd need to do, but I did it anyway) and the result is the same. It won't select the new SIP trunks no matter what I try.
I didn't try removing the original SIP trunk from that RG yet and I don't want to do it during the business day, but I could try that after hours and see what happens then.
Any ideas about why it won't use the new SIP trunks even though they're in service and at the top of the RG list (higher priority), above the original SIP trunk? My RG is set for top down, not circular.
Question #2:
Here's a somewhat related question. (screenshot attached for this one) I first thought I could simply go to the original SIP trunk and add the other IP addresses for the ofther MS UM servers so I wouldn't need to create more SIP trunk groups for this. Maybe I'm understanding it wrong, so please enlighten me what these fields are really used for. On the SIP trunk page, there's a SIP Information section and that's where you add the IP address of the device CUCM is talking to (Destination). For example, the MS UM server. Was I wrong to assume that if the SIP trunks would be identical in their config you can simply add the other IP addresses for the alternate MS UM servers here in this section of the SIP trunks page? What exactly would the extra IP address fields be used for (when you click + to added another address)?
As soon as I added a second IP address, my calls to MS UM stopped working. After I removed the second IP (which is for an alternate MS UM server), everything started working again. Just curious how that IP address field should really be used. For now, I simply created new SIP trunk groups for the other MS UM servers.
Thanks :-)Hello,
For me both questions are related, and I expect a communication issue between CUCM and the new MS UM server.
I would like to start with the 2nd question as it answers both, the below is mentioned in the admin guide of CUCM 8.5 but no much explanation was added to the admin guide of 10.0:
"•When an outbound call gets placed, a destination address gets chosen randomly. No preference is given to one destination address over another. All SIP messages that are sent out for a given outbound call go to the same destination address.
•The SIP trunk accepts inbound messages from any of the configured destination addresses."
The above answers your inquiry, redundancy cannot be achieved by configuring multiple destinations. And calls are dropped when you add the new ip address within the same trunk, because it was chosen but the CUCM was not able to communicate with it, and also this explains why the new MS UM server trunk was not selected in the RG, as CUCM also was not able to communicate with it and moved to the next member in the RG (i.e. the old MS UM).
- Can you try to ping the new MS UM server from CUCM server, SSH to CUCM server and issue the following command: utils network ping IP_ADDRESS_OF_NEW_MS_UM
- It can be that the new MS UM server is configured to accept only SIP UDP messages, can you try changing it from the SIP security Profile?
If the above two suggestions did not help to isolate the issue, then we need detailed CCM logs covering test outgoing call together with the IP addresses of both MS UM servers.
Thank you,
Shadi -
Unable to place call on calls on hold - SIP Trunk from CUCM to CUBE and from CUBE to ISTP
Hi Cisco Community,
I have a SIP Trunk setup between the CUCM and CUBE and another SIP Dial Peers from the CUBE to the ITSP. All incoming/outgoing calls, DTMF-Relay works well except one thing which is the ability to hold the call.
On the SIP Trunk from the CUCM to the CUBE, I did not select “MTP” because when I do so, I am forced to select my preferred MTP codec which when selected G.729/G.729a, all my outgoing calls goes out using G.729r8. This codec works well for most of the calls until the ITSP replies back with G.729br8. When this condition occur, my call simply fails (this is very intermittent and only some random numbers).
That said, I have some issues with DTMF Relay when I select MTP on the SIP Trunk. DTMF Relay only works if the call is G.729r8 all the way from the CUCM to the ITSP. If the ITSP replies back with G.729br8, the call might established but will simply be “voice-only”.
The current setup is no MTP is selected and everything is working perfectly. I am happy with that until I place a call on hold, which when I do so, the call immediately terminate. Could you please help me understand why?
I have all media resources configured such as G.729r8 MTP, G.729br8 MTP, G.711u MTP, Transcoding with all codecs, etc. All MRG and MRGL are configured on all devices and SIP Trunks.
Below is an example of a call that is connected with the current setup:
Note:
IP: 10.18.81.2 (CUBE)
IP: 10.18.81.11 (CUCM SUB)
IP: 10.111.111.254 (ITSP SBC)
PM-HO-VG-01#
PM-HO-VG-01#
Nov 30 11:44:29.938: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.18.81.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
Session-Expires: 1800
Contact: <sip:[email protected]:5060>
Max-Forwards: 70
Content-Length: 0
Nov 30 11:44:29.942: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:29.946: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1417347869
Contact: <sip:[email protected]:5060>
Call-Info: <sip:10.18.81.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 301
v=0
o=CiscoSystemsSIP-GW-UserAgent 7676 6958 IN IP4 10.18.81.2
s=SIP Call
c=I
PM-HO-VG-01#N IP4 10.18.81.2
t=0 0
m=audio 22256 RTP/AVP 18 0 8 101
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Nov 30 11:44:29.950: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Nov 30 11:44:30.658: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Session Progress
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Session: Media
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:30.662: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2747 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:31.226: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Session Progress
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Session: Media
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
X-BroadWorks-Correlation-Info: bbf9
PM-HO-VG-01#4839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC72218
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 101 INVITE
Timestamp: 1417347869
Supported:
Contact: <sip:[email protected]:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Accept: application/media_control+xml,application/sdp,application/xml
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 355
v=0
o=BroadWorks 316169737 1 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 10.111.111.254
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:31.630: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC81D00
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:31.634: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72063a5aba5d
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2747 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:31.726: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72075e3a02c1
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:29 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 236
v=0
o=CiscoSystemsCCM-SIP 9082578 1 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 10.18.80.40
b=TIAS:8000
b=AS:8
t=0 0
m=audio 21928 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 10.18.80.40
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
PM-HO-VG-01#
Nov 30 11:44:31.730: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 10.18.80.40
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
PM-HO-VG-01#sh sip
PM-HO-VG-01#sh sip-ua call
PM-HO-VG-01#sh sip-ua calls
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
SIP UAC CALL INFO
Call 1
SIP Call ID : [email protected]
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 27218091323
Called Number : 0862000000
Bit Flags : 0xC04018 0x10000100 0x0
CC Call ID : 64511
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : [10.111.111.254]:5060
Destn SIP Resp Addr:Port: [10.111.111.254]:5060
Destination Name : 10.111.111.254
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 64511
Stream Type : voice+dtmf (0)
Stream Media Addr Type : 1
Negotiated Codec : g729br8 (20 bytes)
Codec Payload Type : 18
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [10.18.81.2]:22256
Media Dest IP Addr:Port : [10.111.111.254]:20074
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Client(UAC) calls: 1
SIP UAS CALL INFO
Call 1
SIP Call ID : [email protected]
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : 0218091323
Called Number : 0862000000
Bit Flags : 0xC0401E 0x10000100 0x80004
CC Call ID : 64510
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : [10.18.81.11]:5060
Destn SIP Resp Addr:Port: [10.18.81.11]:5060
Destination Name : 10.18.81.11
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 64510
Stream Type : voice+dtmf (1)
Stream Media Addr Type : 1
Negotiated Codec : g729br8 (20 bytes)
Codec Payload Type : 18
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [10.18.81.2]:22350
Media Dest IP Addr:Port : [10.18.80.40]:21928
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
PM-HO-VG-01#
PM-HO-VG-01#
PM-HO-VG-01#
As you can see, the call is connected and everything is working perfectly. When I press the hold button, here is what I get:
NOTE: I have # debug ccsip messages and #debug ccsip calls (running)
PM-HO-VG-01#
PM-HO-VG-01#
Nov 30 11:44:49.210: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsCCM-SIP 9082578 2 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:8000
b=AS:8
t=0 0
m=audio 21928 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Nov 30 11:44:49.218: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 102 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:49.218: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC9241
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Max-Forwards: 70
Timestamp: 1417347889
Contact: <sip:[email protected]:5060>
Call-Info: <sip:10.18.81.2:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7676 6959 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 22256 RTP/AVP 18 101
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3EC9241
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 102 INVITE
Timestamp: 1417347889
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp,application/xml
Contact: <sip:[email protected]:5060;transport=udp>
X-BroadWorks-Correlation-Info: bbf94839-a234-4237-95e6-a7037322f0f4
Content-Type: application/sdp
Content-Length: 360
v=0
o=BroadWorks 316169737 2 IN IP4 10.111.111.254
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 20074 RTP/AVP 18 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
a=inactive
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:49.278: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 0.0.0.0
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.282: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECA2633
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:49.282: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720852ab8b92
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2748 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 22350 RTP/AVP 18 101
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Nov 30 11:44:49.282: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e72094953dfea
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Content-Length: 0
Nov 30 11:44:49.290: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:[email protected]:5060>
Content-Length: 0
Nov 30 11:44:49.294: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 103 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Content-Length: 0
Nov 30 11:44:49.294: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECB16F3
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1020645888-0000065536-0000124117-0189862410
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 103 INVITE
Max-Forwards: 70
Timestamp: 1417347889
Contact: <sip:[email protected]:5060>
Expires: 180
Allow-Events: telephone-event
Content-Length: 0
Nov 30 11:44:49.338: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECB16F3
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
CSeq: 103 INVITE
Timestamp: 1417347889
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported:
Accept: application/media_control+xml,application/sdp,application/xml
Contact: <sip:[email protected]:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 306
v=0
o=BroadWorks 316169737 3 IN IP4 10.111.111.254
s=-
c=IN IP4 10.111.111.254
t=0 0
m=audio 20074 RTP/AVP 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
Nov 30 11:44:49.342: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 2
PM-HO-VG-01#00 OK
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720a6918040f
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 103 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Length: 289
v=0
o=CiscoSystemsSIP-GW-UserAgent 7965 2749 IN IP4 10.18.81.2
s=SIP Call
c=IN IP4 10.18.81.2
t=0 0
m=audio 22350 RTP/AVP 18 101 19
c=IN IP4 10.18.81.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
Nov 30 11:44:49.350: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.11:5060;branch=z9hG4bK2e720b594cd517
From: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
To: <sip:[email protected]>;tag=3C365010-1E42
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 213
v=0
o=CiscoSystemsCCM-SIP 9082578 3 IN IP4 10.18.81.11
s=SIP Call
c=IN IP4 10.18.81.10
t=0 0
m=audio 4000 RTP/AVP 18
a=X-cisco-media:umoh
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=sendonly
Nov 30 11:44:49.354: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECC55
From: <sip:[email protected]>;tag=3C365010-1E42
To: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Max-Forwards: 70
Timestamp: 1417347889
CSeq: 101 BYE
Reason: Q.850;cause=86
P-RTP-Stat: PS=874,OS=17480,PR=872,OR=17440,PL=0,JI=0,LA=0,DU=17
Content-Length: 0
Nov 30 11:44:49.354: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECD1ECD
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Max-Forwards: 70
Timestamp: 1417347889
CSeq: 104 BYE
Reason: Q.850;cause=65
P-RTP-Stat: PS=872,OS=17440,PR=952,OR=19040,PL=0,JI=0,LA=0,DU=17
Content-Length: 0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Race Condition
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECD1ECD
From: "Bianca Africa" <sip:[email protected]>;tag=3C364D44-9E2
To: <sip:[email protected]>;tag=71913148-1417348035284
Call-ID: [email protected]
Timestamp: 1417347889
CSeq: 104 BYE
Content-Length: 0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D7B1458
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 27218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.111.111.254:5060
Destn SIP Resp Addr:Port : 10.111.111.254:5060
Destination Name : 10.111.111.254
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22256
Destn IP Address (Media): 10.111.111.254
Destn IP Port (Media): 20074
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.374: //64511/3CD5D2000001/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 65
Disconnect Cause (SIP) : 200
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.81.2:5060;branch=z9hG4bK3ECC55
From: <sip:[email protected]>;tag=3C365010-1E42
To: "Bianca Africa" <sip:[email protected]>;tag=9082578~cdf4c5a6-dd2b-4c71-bca0-b262ad997720-44517224
Date: Sun, 30 Nov 2014 11:44:49 GMT
Call-ID: [email protected]
CSeq: 101 BYE
Content-Length: 0
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x3D816D70
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 0218091323
Called Number : 0862000000
Source IP Address (Sig ): 10.18.81.2
Destn SIP Req Addr:Port : 10.18.81.11:5060
Destn SIP Resp Addr:Port : 10.18.81.11:5060
Destination Name : 10.18.81.11
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream : 1
Negotiated Codec : g729br8
Negotiated Codec Bytes : 20
Nego. Codec payload : 18 (tx), 18 (rx)
Negotiated Dtmf-relay : 6
Dtmf-relay Payload : 101 (tx), 101 (rx)
Source IP Address (Media): 10.18.81.2
Source IP Port (Media): 22350
Destn IP Address (Media): 0.0.0.0
Destn IP Port (Media): 21928
Orig Destn IP Address:Port (Media): [ - ]:0
Nov 30 11:44:49.406: //64510/3CD5D2000001/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC) : 86
Disconnect Cause (SIP) : 200
PM-HO-VG-01#Hi Manish,
Again, excellent feedback. Much appreciated.
I will try the commands suggested above and see if I can get DTMF to work correctly while interworking H.323 and SIP.
But my ultimate goal is to have SIP all way from the CUCM to the CUBE and from the CUBE to the ITSP.
If I enable SIP Early Offer with MTP on the CUCM going to the CUBE, all SIP Invite sent from the CUCM to the CUBE uses G.729r8 as the codec and once the call is established using G.729r8 should the ITSP reply with that codec, the call succeed and I am able to see an active MTP session using G.729 when I issue the command # show sccp connections.
One thing that I saw is that my ITSP love so much sending G.729br8 most of the times, so even if using SIP EO with MTP on the SIP Trunk to the CUBE, when I sent my INVITE out from the CUCM to the CUBE using G.729r8, specially on call center numbers such as 0800 numbers, you will see that the call established but the codec being negotiated is G.729br8 which is voice only (missing DTMF).
I will be doing some intensive test again later on this week and will send the logs.
Here is my question to both of you:
Which is the best way of having a proper SIP to SIP setup all the way that will not pose any problem?
Do I have to enable Early Offer on the SIP Profile used by the CUBE SIP Trunk or should I use the normal Standard SIP Profile? Do I need to enable MTP on my CUBE SIP Trunk or not?
From the CUBE point of view, I have a voice class codec that support G.729r8 or G.729br8 and the DTMF Relay method supported by the ITSP is RFC 2833.
I will send more logs for each scenario. I think that we are getting close to the resolution of this problem.
Thanks again for your support fellows. -
CME SIP issue - Cisco 7821 phone not registering
Hi
I am having issues with getting a Cisco 7821 phone to register.
Current deployment is with Cisco 6921 phones SCCP registration
SIP integration with CUE
SIP integration with Mitel system
c2951-universalk9-mz.SPA.154-3.M1.bin (CME 10.5)
In flash:
rootfs78xx.10-1-1SR1-4.sbn
kern78xx.10-1-1SR1-4.sbn
sboot78xx.10-1-1SR1-4.sbn
sip78xx.10-1-1SR1-4.loads
The 7821 phone gets IP address but fails to register. Please could somebody let me know why phone is not registering.
Configuration below (10.245.226.132 is CME address) .
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol pass-through g711ulaw
modem passthrough nse codec g711ulaw redundancy maximum-sessions 5
h323
sip
registrar server expires max 600 min 60
options-ping 90
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
voice register global
mode cme
source-address 10.245.226.132 port 5060
max-dn 30
max-pool 10
load 7821 sip78xx.10-1-1SR1-4
authenticate register
authenticate realm all
timezone 22
date-format D/M/Y
voicemail 590
tftp-path flash:
create profile sync 0061443538560005
network-locale GB
voice register dn 1
number 1010
name user1
label user1
mwi
voice register pool 1
busy-trigger-per-button 2
id mac F09E.636E.63F2
type 7821
number 1 dn 1
presence call-list
dtmf-relay rtp-nte
username 1010 password 123
codec g711ulaw
no vad
dial-peer voice 391 voip
description *** Auto Attendant ***
destination-pattern 399
session protocol sipv2
session target ipv4:10.245.226.131
dtmf-relay sip-notify
codec g711ulaw
no vad
dial-peer voice 392 voip
description *** Administration Via Telephone ***
destination-pattern 392
session protocol sipv2
session target ipv4:10.245.226.131
dtmf-relay sip-notify
codec g711ulaw
no vad
dial-peer voice 393 voip
description *** Extension Assigner ***
service ea out-bound
destination-pattern 393
session target ipv4:10.245.226.132
dial-peer voice 590 voip
description *** Voice Mail Pilot ***
destination-pattern 590
b2bua
session protocol sipv2
session target ipv4:10.245.226.131
dtmf-relay sip-notify
codec g711ulaw
no vad
dial-peer voice 1 pots
description ** Match all incoming POTS calls **
translation-profile incoming IncomingPSTNcalls
incoming called-number .
direct-inward-dial
dial-peer voice 899 voip
description Call to Mitel
translation-profile incoming Prefix9
translation-profile outgoing rem44
destination-pattern [23]..
session protocol sipv2
session target ipv4:192.168.114.2
voice-class codec 1
dtmf-relay rtp-nte
no vad
interface GigabitEthernet0/0
description *** Connection to Mitel Phone System ***
ip address 192.168.114.5 255.255.255.248
duplex auto
speed auto
interface ISM0/0
description *** Connection to Cisco Unity Express ***
ip unnumbered GigabitEthernet0/1
service-module ip address 10.245.226.131 255.255.255.128
!Application: CUE Running on ISM
service-module ip default-gateway 10.245.226.132
interface GigabitEthernet0/1
description *** Connection to IP Phone LAN ***
ip address 10.245.226.132 255.255.255.128
duplex auto
speed auto
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip http path flash:
ip route 0.0.0.0 0.0.0.0 10.245.226.129
ip route 10.245.226.131 255.255.2
tftp-server flash:apps37sccp.1-4-4-0.bin
tftp-server flash:sip78xx.10-1-1SR1-4.loads
tftp-server flash:rootfs78xx.10-1-1SR1-4.sbn
tftp-server flash:sboot78xx.10-1-1SR1-4.sbn
sip-ua
mwi-server ipv4:10.245.226.131 expires 3600 port 5060 transport udp
registrar ipv4:10.245.226.132 expires 600
gatekeeper
shutdown
telephony-service
authentication credential cmeadmin c4p1ta2012
xml user xmladmin password xmladmin 15
extension-assigner tag-type provision-tag
max-ephones 104
max-dn 299
ip source-address 10.245.226.132 port 2000
auto assign 101 to 105
no service directed-pickup
timeouts interdigit 5
system message CFGS
url services http://10.245.226.131/voiceview/common/login.do
url authentication http://10.245.226.132/CCMCIP/authenticate.asp
cnf-file location flash:
cnf-file perphone
load 7931 SCCP31.9-2-1S
load 6921 SCCP69xx.9-2-1-0
time-zone 22
date-format dd-mm-yy
voicemail 590
max-conferences 8 gain -6
call-forward pattern .T
moh enable-g711 "music-on-hold.au"
web admin system name cmeadmin secret 5 $1$QmIK$46fDKVSudMxzI2bRp/Ef7/
time-webedit
transfer-system full-consult
transfer-pattern .T
secondary-dialtone 9
create cnf-files version-stamp Jan 01 2002 00:00:00
ephone-dn 298
number 598...
mwi on
ephone-dn 299
number 599...
mwi offPage 7 of the following link recommends that you use option 150 with the Cisco 7800 series phones and use option 66 if you cannot use option 150
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7821_7841_7861/10_1/english/admin_guide/PA2D_BK_AB3F74DA_00_admin-7821-7841-7861-10_0/PA2D_BK_AB3F74DA_00_admin-7821-7841-7861-10_0_chapter_01.pdf
Dynamic Host Configuration Protocol (DHCP)
DHCP dynamically allocates and assigns an IP address to network devices.
DHCP enables you to connect an IP phone into the network and have the phone become operational without your needing to manually assign an IP address or to configure additional network parameters.
DHCP is enabled by default. If disabled, you must manually configure the IP address, subnet mask, gateway, and a TFTP server on each phone locally.
Cisco recommends that you use DHCP custom option 150. With this method, you configure the TFTP server IP address as the option value. For additional supported DHCP configurations, go to the "Dynamic Host Configuration Protocol" chapter and the "Cisco TFTP" chapter in the Cisco Unified Communications Manager System Guide.
Note
If you cannot use option 150, you may try using DHCP option 66. -
ATA187, SIP trunks, CUBE
Hi,
What dial-peer fax statements would be advised in a case where the ITSP (SIP Trunking) only supports g711a pass though for fax?
We are having a hard time making outbound faxes work reliably from a ATA187.
How much 'relay' can/should the gateway do in this case (to my understanding there is no 'relay' in this case)?
Should we rely solely on the ATA187 configuration in CUCM and the settings on the fax machine ? (Speed, ECM, etc)
Gateway/CUBE 15.3, CUCM 9.1.1a
Regards,
Erik
Sent from Cisco Technical Support iPhone AppThe following is an example config you can make use of with an SIP enviroment.
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol pass-through g711alaw
h323
modem passthrough nse codec g711alaw
sip
registrar server expires max 3600 min 3600
asserted-id pai
privacy pstn
options-ping 60
midcall-signaling passthru
dial-peer voice 200 voip
description ----- WYCHODZACE SIP-T ------
destination-pattern [1-9]........
modem passthrough nse codec g711alaw
session protocol sipv2
session target ipv4:SIP-SRV:5020
voice-class codec 23
voice-class sip dtmf-relay force rtp-nte
voice-class sip early-offer forced
voice-class sip pass-thru headers unsupp
voice-class sip pass-thru content unsupp
voice-class sip pass-thru content sdp
dtmf-relay rtp-nte
req-qos controlled-load audio
fax-relay ecm disable
fax protocol pass-through g711alaw
no vad
dial-peer voice 101 voip
description **Outgoing Call to CUCM**
destination-pattern 895216...
session target ipv4:CCM1
voice-class codec 1
voice-class h323 1
voice-class sip dtmf-relay force rtp-nte
voice-class sip early-offer forced
dtmf-relay h245-alphanumeric
fax protocol pass-through g711alaw -
CUCM 10.5.1 and Exchange 2010 Unified Messaging (UM) SIP Trunk Problem
This is more a comment if you're migrating from a lower version to 10.x. Hopefully Google will pickup this post so others don't spend too much time (I got lucky and found this in about 30 minutes).
There are many more SIP options than in the past. If you configured your integration as per the integration doc, all settings are relevant, however there are some new defaults that need to change.
SYMPTOM: Dialing another number or AA pilot and being redirected internally works, but the call drops on calls from external phones. Exchange logs an Event ID 1079 from UMCore and also informational 1084 and 1172 events. A capture yields a status 200 OK, then an ACK, two BYEs and a status 481 that the call leg does not exist. The call is then dropped.
RESOLUTION:
In the SIP Trunk, modifiy the following:
Device Information. . . Check Media Termination Point Required. I've had some that have needed this checked and some where I needed to leave unchecked. In this case going from 7.1 to 10.5 necessitated enabling.
Call Routing Information. . . SIP Privacy: Need to change from Default to None.
Any comments how the SIP Privacy might affect security and functionality would be appreciated.Just to inform everyone. I rebuilt the edge server from scratch.
Now everything is working as expected.
I cannot work out how the edge was not passing on calls to exchange or not communicating correctly with exchange.
Anyway it is resolved now. -
Hi All,
I have an issue here. The DTMF is not recognized by the Unity when user wants to do remote login to voicemail box by pressing *
Call Flow : T1 --> AS5400 --> SIP Trunk --> CUCM 9.1.2 --> SCCP --> CUC 9.1.2
Time : Nov 12 20:06:56.417 UTC
Calling Party Number i = 0x1183, '914466553077'
Called Party Number i = 0xA1, '2067677' - 99992067677
I can see in CCAPI, * being pressed and NOTIFY message is sent to CUCM, and I get 403 Forbidden as response.
The dial-peer configuration point to CUCM is below
dial-peer voice 4320 voip
tone ringback alert-no-PI
description --- PSTN to XXX 9999.XXXXXXX ---
preference 1
destination-pattern 9999.......$
no modem passthrough
session protocol sipv2
session target ipv4:XXXXX
voice-class codec 1
voice-class sip early-offer forced
voice-class sip options-keepalive
dtmf-relay sip-notify rtp-nte
fax rate 7200
ip qos dscp cs3 signaling
no vad
Logs are attached. Please help me to find out the issue.ok..We need to use a different approach to resolve this..We need to prefix calls coming from cucm so as to break up the overlapping issue..
do this..
go to cucm, search for the Route list you use for outbound calls, click on the route group associated with it.
Under called party xformation
under discard digits: use to none
prefix digit outgoing calls: add 141 as shown below -
Hello,
We have a VC system with public IP address registered to VCS-E receiving various rogue SIP calls. All of these SIP calls are 3 - 6 digit alias lasting for 32 sec each. The incoming call address is: alias@ our VC system's public IP address. All calls are video calls at 384k
To avoid the calls, I have turned off the SIP option and since then we have not received any of these calls. However, we need to connect to other devices using SIP. Is there another way to stop these incoming calls?
Thanks in advance for your help.
AmritSet the following on your endpoints:
xConfiguration SIP ListenPort: Off
xConfiguration SIP Profile 1 Outbound: On
See bug CSCue55239 for more details.
You'll also need to take steps to secure your VCS if you haven't already, turning off SIP UDP will stop the SIP calls. However, within the last year we've seen these calls come over H323 TCP, the only way to stop the H323 calls is either secure the endpoint behind your firewall, and use a CPL script on the VCS. See the sourceh323idcisco-incomingcalls discussion on how to setup a CPL.
FYI, searching the forums would be my first place to look, or bug search. It's been asked all over the place in the forums. -
Hi all,
In order to set a PBX and use SKYPE as provider. Could someone give me some answers on SKYPE features. Thanks in advance for your help in aswering
What protocol does SKYPE use UDP or TCP?
Which Keep alive mechanism does SKYPE use SIP OPTIONS or ICMP (ping)???
What codec are supported G729, G711,G723...?
What framing is supported??
Is CLIP supported?
Is CLIR supported?
Is COLP supported?
Is COLR supported?
Does SKYPE support the Digest authentication scheme (MD5).
Does SKYPE support T38??
Does SKYPE support G711 fax ? or G711 with T38 Failover??
Does SKYPE suuport RFC 4733 (RFC 2833 compliant): Payload Type negotiation in outgoing and incoming calls??
What does SKYPE use for “session timer” Re-INVITE or UPDATE?
In calls with HOLD is the codec supported with Re-INVITE messages??
In forwared calls does SKYPE use 302 Moved Temporarily message??
For transferred calls does SKYPE use REFER??
Does Skype use supports the reception of UPDATE messages with SDP?
Does Skype sent PRACK messages with SDP?Yes the Contacts Bar has been updated but why aren't default settings carried over from the Contacts folder.
In the Contacts Folder you can select the default telephone number for Voice Calls, Messages, Email address etc but this information is not copied to a contact when you place them on the Contacts Bar. If you select a contact from the bar you then have to select the mode of contact i.e.. telephone call, message etc. Then you have to select the number you want to contact. Quite a serious niggle to what is overall a greatly improved Contacts Bar.
Maybe you are looking for
-
Oracle 8.1.7 install on Red Hat 8.0 or 7.2
I have been trying to install Oracle 8.1.7 on both Red Hat 8.0 and 7.2 and have followed all the instructions as per the install documents as well as the tips/tricks posted at various tech websites such as http://www.puschitz.com/ and so on. I am not
-
Deleting groups of photos on iPad
I want to delete 500 photos that I have on my iPad, and can't find any way to do it other than one by one... I thought I'd be able to access them from iTunes, but cant
-
CentOS 5.4 64 bit srss 4.2 troubles #2
Hi in my last post "CentOS 5.4 64 bit srss 4.2 troubles" at http://forums.sun.com/thread.jspa?messageID=10968761 I managed to get the sun rays working as thin clients off my new CentOS 5.4 64 bit server thanks to the help of ottomeister and joergb Al
-
November 18 Midnight Openings?
So I checked out the Gaming Events page for the midnight openings next week, and on all of my local stores there is no information about it (nor have the news or events been updated in a number of months); is it safe to assume that there won't be any
-
Hi folks, I need some help. I have my laptop with Win XP SP2, one cable modem, and one WRT54G. All work, the problem is that i can't use the remote assistance with Windows Live Messenger, when the friends ask me to help them the remote try to connect