7925G - Can it respond to SIP Invite values?
We are working on an integration with a third party vendor for a nurse call system. We have 600 or so 7925G phones, obviously running SCCP.
I know the phones can respond to ring tone selection via XML controls being sent directly to the phone.
The vendor's system is connected via a SIP trunk, and two-way audio works as it needs to.
Question is - the vendor can specify a ringtone file in their SIP Invite. Does SCCP even have an awareness of that information coming through, and if so, does it have an ability to act on it? I suspect know, but this is so arcane I'm not searching right to find out for sure thus far.
The 7921 and 7925 are SCCP only. No SIP support on them.
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps379/ps9900/data_sheet_c78-504890.html
The phone will be able to comunicated with a SIP leg as long as MTP its between.
Now regarding the "ring tone", I am guessing your 3 party set it in a SDP field, (in order to point out an specific ring tone).
I am afraid the Phone its unable to see this field and act (play a differnt ring tone) base on this.
Please Kudos/rate if this help!
Similar Messages
-
Cannot respond to Calendar Invites
Hello,
I can not respond to Calendar Invites on my Z10 that originate from another Z10.
I have two devices here, and when I send a calendar invite from one device to the other using an outlook.com email address, the other device receives the event, however displays a message saying "You have already responded to this event" (see attachement). The buttons to accept/reject/tentative are also not available.
Notes:
- Both devices use outlook.com email addresses set to sync via ActiveSync
- When an invite that originates from the Web (outlook.com) and is sent to either of the Z10 devices I am able to respond to the event invite
- When an invite that originates from a Z10 is sent to an email address I am able to respond to the event invite from the Web
Things I've tried:
- Deleting and readding the accounts to the devices
- Turning on/offf Calendar syncing
Would anyone have any ideas how to address this?
Thanks so much.
Neil
Neil M.
Twitter: @neilmispelaar
Attachments:
IMG_00000003.png 114 KBI'm having the exact same issue when I send meeting invites to people through my hotmail ActiveSync account on my Z10. They experience the exact same behaviour as you described on their Z10s as well.
From my Z10 I viewed the sent meeting invitations in my hotmail sent items folder and compared invitations I'd sent from my hotmail account in my PC web browser, and invitations I'd sent from my Z10. I noticed that those sent from my web browser appear as proper meeting invitations. Those that I'd sent from my Z10 appear as sent email addresses with an attachment named "meeting.ics". So, I'm guessing the Z10 isn't processing the .ics attachment 100% correctly.
I tested this by sending meeting invitations from my Z10 to a colleague who is on BES (Exchange) and observed same described behavior on her Z10, but in her PC Outlook client the invitation worked as expected.
I hope someone can assist! -
Get '500 Internal Server Error' during SIP INVITE - cause 44
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Get ‘500 Internal Server Error’ during SIP INVITE - cause 44
Have you ever seen anything like this before? It usually works, but intermittently, we see calls get rejected. It somehow seems related to high loads on the router. We reduced the occurrences by changing our code to throttle the number of SIP INVITEs we send, but this doesn’t scale well. Once it occurs, the only way to clean it up is to do a shut/no shut on the voice-port associated to SIP INVITE.
Any suggestions on how we can proceed to debug this issue?
BACKGROUND:
Cisco 2811 running (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)
NAME: "2811 chassis", DESCR: "2811 chassis" PID: CISCO2811
NAME: "9 Port FE Switch on Slot 0 SubSlot 1", DESCR: "9 Port FE Switch" PID: HWIC-D-9ESW
NAME: "WIC/VIC/HWIC 1 Power Daughter Card", DESCR: "9-Port HWIC-ESW Power Daughter Card" PID: ILPM-8
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 2", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 3", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "PVDMII DSP SIMM with four DSPs on Slot 0 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "High Density Voice2 Network module with on board two port interface on Slot 1", DESCR: "High Density Voice2 Network module with on board two port interface " PID: NM-HDV2-2T1/E1
NAME: "2nd generation two port EM voice interface daughtercard on Slot 1 SubSlot 0", DESCR: "2nd generation two port EM voice interface daughtercard" PID: VIC2-2E/M
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 2", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 3", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 5", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
WIRESHARK:
No. Time Source Destination Protocol Info
2 0.057246 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 2 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
3 0.071428 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 3 (1109 bytes on wire, 1109 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
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-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
4 0.089917 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 4 (1116 bytes on wire, 1116 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
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-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
7 1.661867 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 7 (469 bytes on wire, 469 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
8 1.676056 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 8 (1107 bytes on wire, 1107 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
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-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
10 1.700567 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 10 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
11 1.726376 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 11 (1114 bytes on wire, 1114 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
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-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
13 1.727645 10.194.154.136 171.68.115.156 SIP Status: 500 Internal Server Error
Frame 13 (526 bytes on wire, 526 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 500 Internal Server Error
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>;tag=4864C50-3C3
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=44
Reason Protocols: Q.850
Cause: 44(0x2c)[Requested circuit/channel not available]
Content-Length: 0
Thanks!
-JohnSince it appears you are a Cisco Employee, my recommendation is that you use the many internal resource available to you (including, but not limited to) , like TAC access, internal forums, team leaders, etc.
This not to give the casual reader, the impression that the best source of support at Cisco is a customer's public forum. -
Lync 2010 client does not offer any NON-direct UDP Candidates in its SIP Invite' SDP - why?
Hello.
We have a customer, experiencing the following issue.
They have big multi-continental Lync Server 2010 Enterprise Edition deployment, with non-NAT'ted Edge Pool.
The call scenario is simple: peer-to-peer video (A/V) call between external Lync client and Video system, Cisco VCS
in this case but does not matter, which (video system) only supports media over UDP (which is nothing strange). The VCS has a lot of video endpoints all over the Globe, Lync clients are also everywhere, so call can be any "distance", not predictable.
All video endpoints are registered on this single VCS.
The video call, as I suspect, only succeeds IF direct peer-to-peer UDP connection works and fails otherwise.
I skip the overall design, keeping here only what is relevant.
Video system offers only its own local IP as UDP candidate (type = host), which in this particular
case is expected, let's assume there is no TURN etc expected on video system' side, it is directly Internet-facing.
Now the main bit. Lync client offers ALL proper TCP candidates: both local AND non-local, using external
public IP addresses of both A/V Edge Hardware LoadBalancer VIP and public IP address of one of Edge servers.
Those candidates are enlisted perfectly fine (I checked carefully), so SIP INVITE has them all offered.
Now: the Lync 2010 client ONLY offers direct/local UDP candidate (type = host) with its own IP address,
but does NOT offer any NON-local UDP Candidates at all (while, again, for TCP candidates the full set of non-local (A/V Edge) ones is offered).
WHY this can happen?
Again my guess on where to dig is: TCP candidates (which are completely useless for such video call)
are all offered fine with A/V Edge's public IPs, both VIP and particular node ones. Does this fact make sense?
WHAT can be the reason why the same or similar remote/Edge Candidates are not being
offered/enlisted for UDP while for TCP they are offered?
What I already found, to be excluded easily: the whole client sign-in and in-band provisioning is OK, all about
certificates is Ok, and all about MRAS URI and MRAS Credentials (looking sign-in traces) is also fine. Client gets proper MRAS username/password and ALL about signaling before SDP is also fine (no TLS or MRAS related errors).
I cannot rule-out potential DNS issues at the moment, however unlikely: otherwise how it would get proper list
of NON-local TCP candidates and all SIP signalling with the Edge working Ok if it would be DNS-specific issue?
What, however, I have not confirmed is: UDP port 3478 is most likely NOT opened on/between all of the involved parties (Edge's private and public interfaces, Hardware LoadBalancer's interfaces and client),
and/or UDP 3478 communication is most likely getting blocked completely (when the client is external), however for instance TCP 443 is everywhere opened.
Can THIS be somehow related to why it properly allocates non-local TCP but none of
non-local UDP Candidates?
What traces show on call negotiation is ICE Connectivity Failed and/or ICE Warning - I have real it carefully, did WireShark'ing, what I suspect is: simply ICE Connectivity Checks fails on direct P2P UDP which is of course expected, and because no non-local
UDP candidates are offered and TCP is not allowed on video system' side - it fails. WireShark shows the following: millions of outgoing UDP from the client to Cisco VCS and not even one INcoming UDP back from VCS.
Sometimes, depending on the external client's location, call, however, succeeds. I guess (guess)
this is because SOMETIMES direct UDP flows Ok, while in vast majority of the cases it expectedly does not.
Big thanks.
/roubchiHi,
VideoendpointsonlysupportUDPmedia.ICEusuallyoffers3candidates: Host(privateIP), ServerReflexive(outsideIPaddressoffirewalllocaltothemediasupplyingagent–B2BUAorLyncClient),
TURNserver(typicallytheEdgeServer/VCSExpressway)
You can refer to the link of “Cisco
VCS and Microsoft Lync Deployment Guide (X8.1)” to check the configuration of Lync integrated with Cisco VCS.
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support -
SIP Invite change for anonymous calls
I noticed a change in IOS Gateways in how it deals with anonymous calls. Anonymous calls in version 12.4(25g) generates an SIP INVITE:
From: "anonymous" <sip:[email protected]>
A anonymous calls on version 15.1(4)M8 generates a SIP INVITE:
From: "anonymous" <sip:[email protected]>
The p-asserted-identity and remote-party-id did not change. None of our other SIP systems use the "anonymous@" format.
How do I get the 15.1 GW to use "<number>@" instead of "anonymous@" for these calls?
Thanks,
-JohnHi John,
The only possible solution that i could think of for this scenario is through the use of SIP profiles on the gateway. There are quite a few posts and docs which you can check to try and configure one for your setup
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/105624-cube-sip-normalization.html
http://www.gossamer-threads.com/lists/cisco/voip/127376
HTH
Manish -
Am setting up a SIP trunk on a UC520. Outbound calling is working fine. Inbound is not.
The SIP invite comes in but is rejected with a: SPI_validate_own_ip_addr: ReqLine IP addr
does not match with host IP addr
I suspect this is caused by the fact that the invite is using the sender IP and not my (recipient IP)
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
As a way to test, I created a tunnel interface with the 208.65.240.44 address, and the call rings through.
The question is, Is there a way to disable SPI validation on a UC520, as i doubt I can get the SIP provider to fix their Invite string?Am setting up a SIP trunk on a UC520. Outbound calling is working fine. Inbound is not.
The SIP invite comes in but is rejected with a: SPI_validate_own_ip_addr: ReqLine IP addr
does not match with host IP addr
I suspect this is caused by the fact that the invite is using the sender IP and not my (recipient IP)
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
As a way to test, I created a tunnel interface with the 208.65.240.44 address, and the call rings through.
The question is, Is there a way to disable SPI validation on a UC520, as i doubt I can get the SIP provider to fix their Invite string? -
Does SPA122 support a custom "From" header in SIP INVITE msg?
Our SIP service provider allows me to specify the calling line identification (CLI) for outgoing calls by placing the appropriate string in the "From" field of the SIP INVITE msg.
This is independent of the "User ID" needed to register with the service.
Does the SPA122 provier a way to specify a suitable "From" string?You can use the 'Display Name' field to send another name or number out to the other side.
-
Hi all,
for authentication reason our SIP provider requires the "from: user@host" field in the SIP INVITE message to have a domain.xy as the host section. So far the router (3660 with IOS 12.3(14)T) only uses its ip address as host part.
Does any one know how I can modify the host part to use a predefined domain instead of the ip adress?
Thanks
GunnarHi, this feature is available in IOS 12.4(2).
The format of the command is:
localhost dns:domain.org
in the voice-service-voip / SIP menu
hth -
Good morning,
Please, could you kindly help me with the following matter?
I have some questions regarding how CUCM builds some fields in a SIP INVITE message. Last week I was reviewing logs and I found the below R-URI when an extension calls another extension:
A number--> 7100 ---(1 SIP invite) ----> CUCM ---- (2 SIP invite) ----> B number 7101
1 SIP invite R-URI: sip:[email protected]; user=phone
2 SIP invite R-URI: sip:[email protected]:51544;transport=tcp where
5ea27f5e-033b-880c-e304-0729574bfb1 is the user part.
I thought the first invite should be sip:[email protected]; user=phone. Concerning the invite from CUCM to B number, how does CUCM build the user part from the B number?
Moreover, what are Contact ang tag fields used for in a sip message? how does CUCM build them?
Thanks in advance.
Juan.Juan,
I will explain how a sip phone signals to CUCM when making a call...Two major things happen
1. The first digit dialled is sent in the INVITE
2. The remaining digits are sent via NOTIFY (in the NOTIFY, you will see the digits that are dialled
The trace below details what happens when a sip phone makes a call. I stopped this trace after digit=8 was dialled
Called number=918772888362
Here we get INVITE with SDP from the sip phone to CUCM
29/2010 10:36:33.771 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 1717 bytes:
INVITE sip:[email protected];user=phone SIP/2.0 (first digit dialled =9)
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Call-ID: [email protected]
Max-Forwards: 70
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP9951/9.0.1
Contact:
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Test User 1" ;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,Xcisco-
service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-5.0.0,X-cisco-xsi-9.0.1
Allow-Events: kpml,dialog
Content-Length: 632
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 26964 0 IN IP4 172.18.159.152
s=SIP Call
t=0 0
m=audio 29254 RTP/SAVP 0 8 18 102 9 116 124 101
c=IN IP4 172.18.159.152
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:9 G722/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:124 ISAC/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 25466 RTP/AVP 97
c=IN IP4 172.18.159.152
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E
a=recvonly
+++Next CUCM sends trying++++
03/29/2010 10:36:33.773 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port
51682 index 2321
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Date: Mon, 29 Mar 2010 14:36:33 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
+++++Unified CM Sends a REFER to play Outside Dialtone++++
03/29/2010 10:36:33.780 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 409
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
DtOutsideDialTone
user
++++Unified CM Sends a SUBSCRIBE for KPML++++
03/29/2010 10:36:33.781 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682 index 2321
SUBSCRIBE sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To:
Call-ID: [email protected]
CSeq: 101 SUBSCRIBE
Date: Mon, 29 Mar 2010 14:36:33 GMT
User-Agent: Cisco-CUCM8.0
Event: kpml; [email protected]; from-tag=00260bd9669e07147bcb3aac-3cda8f0c
Expires: 7200
Contact:
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
<?xml version="1.0" encoding="UTF-8" ?>
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">
[x#*+]|bs
++++ Phone Sends 200 OK for the REFER and SUBSCRIBE ++++
03/29/2010 10:36:33.802 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port 51682 index 2321 with 453
bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To: ;tag=00260bd9669e07167c743311-343ee3af
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
Phone Sends 200 OK for the REFER and SUBSCRIBE
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
Unified CM Sends a SUBSCRIBE for KPML
220
++++User Dials a ‘1’, phone sends a NOTIFY to CUCM for the digit++++
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 1001 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="1" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK++++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
++++Unified CM Replies Sends a REFER to Disable Outside Dialtone+++
03/29/2010 10:36:34.353 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 401
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
Dt_NoTone
user
+++Phone Replies With 200 OK to REFER++++
03/29/2010 10:36:34.402 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 453 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To: ;tag=00260bd9669e07184b08b96b-796ab86f
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
++++User Dials a ‘8’, phone sends a NOTIFY to CUCM+++
03/29/2010 10:36:34.944 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 896 bytes:
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK647d03c1
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:34 GMT
CSeq: 1002 NOTIFY
Event: kpml
Subscription-State: active; expires=7195
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="8" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK+++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
As you can see this is similar to what you are seeing...The first digit dialled is seen in the INVITE, the remaining digits will be seen in NOTIFY.
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared" -
SPA303 - Reordering the position of Content-Length header in SIP INVITE
Hi,
I have SPA303 IP Phone connected behind a SIP ALG router but have been facing issues with media setup for incoming and outgoing calls.
Further investigation using SIPp script helped me out to understand the root cause of the issue which is as follows:
If the SIP INVITE or 200 OK for SIP INVITE has Content-Length header ahead of the Content-Type header, the SIP ALG router is not able to handle the RTP traffic for the calls. Cisco SPA303 IP phone exhibits this behaviour and hence couldn't successfully establish call with the SIP ALG that I use.
Can you please confirm if it is configurable to reposition or re-order the Content-Length header to resolve this issue?
Thanks in advance.
Regards,
Anand KrishnanAs far as I know it's not configurable. According SIP protocol, the order of SIP headers is not meaningfull.
Your router need to accept both orders as both are corrrect and have same meaning. Ask the vendor of router for updated firmware ... -
Outlook Users Can't Accept iCal event invites
Microsoft Outlook users can't accept my event invites from iCal.
I already searched through all the possible prefs and settings... at least I think I have.
Can anyone help?
THX!
A.CheTo clarify this issue - (as I am having a similar issue)...
From iCal I can easily accept and respond to meeting requests sent to me from a person using Outlook 2003
The problem is the other way round - My meeting requests from iCal do not seem to be accepted by Outlook. I am generating an email that has a *.ics file extension and it is being sent via mail, but when the recipient (using Outlook 2003) receives the email, it is formatted as plain text and does not have a file attachment.
When that person forwards the message back to me, it DOES have the attachment still attached (which I can open on my own PC).
What is the trick to sending an iCal meeting request to an Outlook user so that they can add it to their calendar (and respond to the request)?? Apparently they receive a plain text email with an attachment that is named "Untitled Attachment" which is then empty (~200 bytes)
Here is a picture of what I am talking about (that they receive in Outlook):
http://screencast.com/t/HntfLYYF5cf
Thanks -
Hello,
How can be configured the CCA that in SIP Invite Request in FROM section of Message Header instead of "sip:system@.... " sip:00061007@...", where 00061007 is the line number?
Thanks for help!
JonSorry, I found solution.
-
Receive and respond to meeting invitations only for Microsoft Exchange
Hello,
On Apple support page it says to iPhone Software version 3.0:
"If you have a Microsoft Exchange account, you can receive and respond to meeting invitations."
That means with MobileMe it's still not possible.
What kind of service is that, if Apple supports Microsoft better than their own service?
Regards,
JOHi All--
I have been looking for this feature with MobileMe. I was hoping that it would have come with 3.0 -- but no luck. It would be really nice for MobileMe users to send/receive/accept/decline event or meeting invites from their iPhone or iCal.
I heard something about event invites in Snow Leopard iCal... will have to wait and see.
Brad -
Lync Federation - Accept SIP Reverse Negotiation (SIP Invite without SDP)
Hello,
Recently I tested a SIP Federation trunk between Lync Server 2013 and non-Lync Client.
In this scenario the Lync Client 2013 support SIP Reverse Negotiation, by other words if SIP Invite without SDP it's sent to Lync Client 2013 it will be accepted by any configuration option?
With the default settings seams that it's not supported with error reason "Error parsing body"
Trace-Correlation-Id: 3549384327
Instance-Id: 4C9
Direction: outgoing
Peer: lynctest.domain.com:2138
Message-Type: response
Start-Line: SIP/2.0 488 Not Acceptable Here
From: "User4" <sip:[email protected]>;tag=3794445243
To: <sip:[email protected]>;epid=abad235729;tag=a130a7e357
Call-ID: [email protected]
CSeq: 12784624 INVITE
Via: SIP/2.0/TLS 172.16.3.51:5065;branch=z9hG4bK-5765F571;rport;alias;received=172.16.3.51;ms-received-port=2138;ms-received-cid=1200
Content-Length: 0
ms-client-diagnostics: 52009;reason="Error parsing body"
Regards,
ClaudioHello All,
After some analysis I got the following conclusions.
Lync PC Client doesn't accept initial Invite without SDP ( Delayed Offer ).
However our goal was to test the SIP Reverse Media Negotiation mechanism, so we sent initially a dummy SDP for the initial invite and after the connect send a SIP INVITE without SDP and for my surprise the Lync Client accepted and sent his own SDP on the
200 OK and we sent the new SDP offer in the ACK.
However the result was no Audio, and Lync Client kept sending the Audio to the initial INVITE SDP and ignored the new SDP offered in the ACK message.
So my conclusion it's that LYNC Client doesn't support SIP Reverse Media Negotiation (Delayed Offer) at all since it ignores the new SDP offered in the ACK message for the mid call media renegotiation attempt with SIP INVITE without SDP.
Traces:
INVITE sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="F5054EF3", snum="104", rspauth="040401ffffffffff0000000000000000e9693240576b479326af5617", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 56
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Contact: <sip:[email protected]:5065;transport=TLS>
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 0
Require: 100rel
Supported: 100rel,replaces,privacy,timer,from-change,histinfo,answermode
User-Agent: (Virtual Appliance)
P-Asserted-Identity: "" <sip:[email protected]>
Session-Expires: 720;refresher=uac
P-Sig-Options: Sending-Complete
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="785246a1", cnum="92", response="040400ffffffffff000000000000000000b60640ac2c60c49bc1b427"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Contact: <sip:[email protected];opaque=user:epid:wc5Y6-kDo16CxuVbyxqk9gAA;gruu>
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-dialog-route-set-update
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="e903d142", cnum="93", response="040400ffffffffff0000000000000000dbe0e9524a1031ef81a19d2f"
Content-Type: application/sdp
Content-Length: 354
v=0
o=- 0 1 IN IP4 172.16.1.87
s=session
c=IN IP4 172.16.1.87
b=CT:99980
t=0 0
m=audio 12530 RTP/SAVP 8 0 13 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:mIMHiJBpn4ZRZfg2VXYSTdQfS4wyJ0x57QQ0q4kU|2^31
a=maxptime:200
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
ACK sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK301D467E.2E943CC97CBC4CCD;branched=FALSE
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CEE;rport;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="B8AB5336", snum="105", rspauth="040401ffffffffff0000000000000000de85d6c7415302c9b7535777", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 69
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 ACK
Contact: <sip:[email protected]:5065;transport=TLS>
Content-Length: 326
Content-Type: application/sdp
v=0
o=- 262 2 IN IP4 172.16.13.192
s=session
t=0 0
m=audio 16392 RTP/SAVP 8 101 13
c=IN IP4 172.16.13.191
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:X0rDwl9KxCJfSsRaX0rEkl9KxNJfSsUCX0rFOtIK|2^31 -
Modify calling number in SIP invite on CUCM 10.5
Hello,
I am working at a customer with CUCM 10.5 who uses MGCP gateways to access the PSTN via T1 PRI ISDN.
They use four digit DNs internally and need to prefix these with 713657 to make the outbound CLID work ok - i.e. a call to the PSTN from extension 1000 needs to send 7136571000 to the ISDN provider.
I configured this using Calling Party Transformations and this works fine e.g.
A Calling Party Transformation for 1XXX would prefix 713657.
The problem I have is that the customer has a NICE active recording system which communicates with the CUCM cluster using a SIP trunk.
The invites that CUCM sends via the SIP trunk show the full ten digits rather than the four digit extension which will not work according to company deploying the recording system.
If I remove the Calling Party Transformation then the SIP invite shows four digits and the call recording works but the outbound CLID does not work.
Can anyone suggest a way to fix this? The customer does not want to change the gateway protocol from MGCP to H323 which would be my favoured choice. Any change of calling party setting on CUCM (e.g. ticking the use external mask for calling party on route pattern) affects the SIP invite.
Ideally I need a way to modify the number in the SIP invite but I cannot find any example of how to do this.
Any suggestions are welcome.
ThanksHi, thanks for your response.
The Calling Party Transformation CSS is not applied to the SIP trunk but is applied to the T1 port of the MGCP gateway.
The Transformations are still applied to the SIP Invite messages via the trunk so I guess this is a quirk of the calling recording profile setup on CUCM.
I did try creating another Calling Party Transformation setup which stripped the unwanted digits and applied it to the SIP trunk but it had no effect.
Maybe you are looking for
-
How to get the Frame size in H.263 by JMF ?
Dear all, How to get the individual frame size in H.263 format if the H.263 file is a format of InputStream ???
-
Link between Fixed Asset and Purchase Order Tables
Hi, I am working in Fixed Asset Report. I have a folllowing Doubts.Please clarify. 1. How to link the Fixed asset tables with PO_HEADERS_ALL 2. I took the Asset_Account field from FA_ASSET_DISTRIBUTIONS_V . But how to link with this table to other Fi
-
I followed all the prompts and plugged my new 4S into my desktop, everything has sync'd but I still can't make any calls. It's obviously not connecting to the network. What am i doing wrong?
-
Commit after n rows while update
i have 1 update query UPDATE security SET display_security_alias = CONCAT ('BAD_ALIAS_', display_security_alias) WHERE security_id IN ( SELECT DISTINCT security_id FROM security_xref WHERE security_alias_type IN ('BADSYMBOL', 'ERRORSYMBOL', 'BADCUSIP
-
ALE IDOC Error 29 - Error in ALE Services
Hi Friends, We are getting error No 29 in ALE Services. In WE20 we created partner profiles and did all the ALE setup activities. Finally we went for post process permit in we02 and we found - Error 29 Error in ALE services. We checked our partner nu