SIP invite error on UC520

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?

Similar Messages

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!
-John

Since 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.

Fax outdial retries consume all voice channels on SIP 484 error (Cisco 2911)

I've been seeing a nasty fax/VoIP problem on a 2911, running IOS 15.0(1r)M12. Any suggestions would be welcome.
I have a 2911 which is set up to do T.37 offramp fax delivery (SMTP message is sent to 2911, which places a VoIP call over SIP/RTP/T.38 to deliver the fax). The mainline case is set up, and working correctly - faxes are delivered without issue. If a destination address is selected such that the VoIP switch returns a SIP 484 error, then everything fails in a spectacular fashion:
The outdial is immediately retried, placing another SIP INVITE to the switch, with the same destination address, which obviously also gets the same 484 response.
Each time the outdial takes place, it consumes voice channels on the DSP, which are not released on receipt of the 484.
When there are no free voice channels, a no circuit (0x22) error is returned, and all the voice channels are finally released.
The MTA that submitted the SMTP message retries every minute (it doesn't get a permanent failure report when the 2911 fails to place the call)
This leads to a situation where no fax calls can be placed, as all the voice channels are being used up by retrying this call that can never succeed.
Some other relevant information:
The VoIP switch does not return a 484 immediately. First it sends a SIP 183, and plays early media (an announcement about how the call isn't allowed).
It takes 8 seconds before the 484 is returned. The 2911 sends a new SIP INVITE every 8 seconds (as soon as it gets a 484 for the previous attempt).
The "sip-ua" statistics show that the INVITE retry counter is not being incremented (i.e. this is not a retry at the scope of the SIP stack).
The T1 cable is looped-back to the 2911, so that the complete path for fax delivery looks like this:
MTA ---SMTP---> 2911 ---T1---> 2911 ---SIP---> VoIP switch
If I set "mta receive generate permanent-error", then I still see this retry behaviour, with all the voice channels being consumed. Once that has happened (after about 3 minutes) the MTA does get the error response, and no longer retries every minute after that (although this setting has other negative effects that I'd like to avoid).
Does anyone have any idea how I can get the 2911 to return a permanent failure to the MTA after just a single outdial has failed with a SIP 484?
Here is the dial-peer config:
dial-peer voice 1 voip
translation-profile incoming IncomingVoip
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 3 hs-redundancy 0 fallback pass-through g711ulaw
no vad
dial-peer voice 2 pots
destination-pattern ^0005
port 1/1:23
forward-digits all
dial-peer voice 3 pots
translation-profile incoming IncomingPRI_1_0
service onramp-app
incoming called-number ^0005
direct-inward-dial
port 1/0:23
dial-peer voice 4 mmoip
service fax_on_vfc_onramp_app out-bound
destination-pattern .
information-type fax
session target mailto:$m$@<DOMAIN NAME>
image encoding MH
dial-peer voice 101 mmoip
translation-profile incoming IncomingMMoIP
service offramp-app
information-type fax
incoming called-number .
dial-peer voice 102 pots
destination-pattern .
port 1/0:23
forward-digits all
dial-peer voice 103 pots
translation-profile incoming IncomingPRI_1_1
incoming called-number ^0007
direct-inward-dial
port 1/1:23
dial-peer voice 104 voip
translation-profile outgoing OutgoingVoip
destination-pattern ^0008
session protocol sipv2
session target ipv4:<VoIP SWITCH IP ADDRESS>
voice-class codec 1
dtmf-relay rtp-nte
fax protocol t38 version 0 ls-redundancy 3 hs-redundancy 0 fallback pass-through g711ulaw
no vad

Hi Ellad.
Why don't try to use the 2811 as a SIP signalling proxy only?
In this way the media (RTP or T.38) will be handled only from the two MERA SoftSwitch.
To do this you must enable CUBE on your 2811 and use these special commands:
voice service voip
     media flow-around
     allow-connections sip to sip
     signaling forward unconditional
     sip
       rel1xx disable
       header-passing
       midcall-signaling passthru
       pass-thru headers unsupp
       pass-thru content unsupp
       pass-thru content sdp
I don't remember if we have already try this solution.
Regards.

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.
/roubchi

Hi,
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

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,
Claudio

Hello 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

SIP invite include update

Hi guys,
We currently have issues with SIP invites from our FE colocated mediation servers to our IP PBX / SIP trunk.
The result causes issues with the mediation server sending SIP messages:
SIP/2.0 491 GatewayCall is not in connected state.
Our SIP trunk provider have identified the cause for this to the fact they are sending SIP updates to the mediation server.
They do this because the mediation server sends "SIP Allow updates":
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE
But according to this document "Partner Specification – SIP Trunking Interoperability ---Wave 15 (Lync Server 2013)"
”Use of the Update method as specified in RFC 3311 is not supported by the Mediation Server over its interface to a Service Provider Proxy .”
But from RFC3311 you can find:
”The Allow header field is used to indicate support for the UPDATE method.”
Do any of you know why the mediation server sends allow update in the invite? is there a way to prevent this?
/Daniel

Hi Guys,
We created a case with Microsoft support and this is a known error.
If anyone else experience this issue please create a case at Microsoft support referring to SR number "114022611216239" to increase Microsoft product team priority to fix this issue.
The conclusion on the case:
"We do not support UPDATE at this time. We are misaligned to RFCs in that we do place UPDATE in the ALLOW header which presupposes support of this method. However, with the offer/answer model of SIP, if the gateway does not receive a response
to the specific method then the GW must assume that the method is unsupported and should continue with the session.
This is known issue and we are working on it."
Our SIP trunk provider have to implement a workaround either removing the Allow update from the SIP invite or ignoring the "SIP/2.0
491 GatewayCall is
not in connected state" response to the SIP update request.
Br.
Daniel

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,
-John

Hi 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

How does a 4G VoLTE UE know the destination SIP URI format to create the SIP INVITE

This trace is the output from an ASR500 for a VoLTE call,
For VoLTE the UE and IMS core network must support Public User Identities as defined in section 13.4 of 3GPP TS 23.003, which includes all of the following types of addresses:
•Alphanumeric SIP-URIs
sip:[email protected]
•MSISDN represented as a SIP URI:
sip:[email protected];user=phone
•MSISDN represented as a Tel URI:
tel:+447700900123
sip:[email protected]
In the SIP SDP you will see: sip:[email protected]
Mobile Originating UE:        sip:[email protected]
Mobile Terminating UE:        tel:+14047808898
Notice the two different formats.....
Below in the initial SIP INVITE you will see that the MO (Mobile Originating) sends the SIP URI in the proper format (1 of 3) to the MT (Mobile Terminating 4G handset).
My questions is: does the MO know the SIP URI format of the MT (User Endpoint / 4G smartphone) because it has some sort of Address Book, or is that the designated format for a SIP INVITE   (to: tel+###########) because he MO knows the MSIDSN (tel number) dialed .
I do not understand how the MO knows how to format the SIP URI format of the MT (Mobile Terminating) and would appreciate any insight into this.
PROTOCOL PAYLOAD FOLLOWS:
2600:100c:8221:6dc9:f77a:8b7:5e38:a5d5.60717 > 2001:4888:3:fe0f:c0:105:0:17.5060: . [tcp sum ok] 1:1357(1356) ack 1 win 214 <nop,nop,timestamp 64706 423317258> (len 1388, hlim 64)
PROTOCOL PAYLOAD ENDS.
PDU HEX DUMP FOLLOWS:
0x0000 30ff 0594 c20d 0073 6000 0000 056c 0640 0            ......s`....l.@
0x0010 2600 100c 8221 6dc9 f77a 08b7 5e38 a5d5 &          ....!m..z..^8..
0x0020 2001 4888 0003 fe0f 00c0 0105 0000 0017                ..H.............
0x0030 ed2d 13c4 e245 e405 fcb6 417e 8010 00d6                .-...E....A~....
0x0040 f720 0000 0101 080a 0000 fcc2 193b 4f0a                 .............;O.
0x0050 494e 5649 5445 2074 656c 3a2b 3134 3034               INVITE.tel:+1404
0x0060 3738 3038 3839 3820 5349 502f 322e 300d                7808898.SIP/2.0.
0x0070 0a4d 6178 2d46 6f72 7761 7264 733a 2037                .Max-Forwards:.7
0x0080 300d 0a52 6f75 7465 3a20 3c73 6970 3a5b                0..Route:.<sip:[
0x0090 3230 3031 3a34 3838 383a 333a 6665 3066                2001:4888:3:fe0f
0x00a0 3a63 303a 3130 353a 3a31 375d 3a35 3036                :c0:105::17]:506
0x00b0 303b 6c72 3e0d 0a56 6961 3a20 5349 502f 0               ;lr>..Via:.SIP/
0x00c0 322e 302f 5443 5020 5b32 3630 303a 3130 2.               0/TCP.[2600:10
0x00d0 3063 3a38 3232 313a 3664 6339 3a66 3737                0c:8221:6dc9:f77
0x00e0 613a 3862 373a 3565 3338 3a61 3564 355d                a:8b7:5e38:a5d5]
0x00f0 3a35 3036 303b 6272 616e 6368 3d7a 3968                     :5060;branch=z9h
0x0100 4734 624b 3030 3033 3335 3933 2d31 6361                G4bK00033593-1ca
0x0110 6630 3633 340d 0a43 5365 713a 2031 2049                f0634..CSeq:.1.I
0x0120 4e56 4954 450d 0a46 726f 6d3a 203c 7369                NVITE..From:.<si
0x0130 703a 2b31 3931 3236 3735 3738 3639 4076                p:+19126757869@v
0x0140 7a69 6d73 2e63 6f6d 3e3b 7461 673d 3534                  zims.com>;tag=54
0x0150 3436 375f 3030 3033 3339 6130 2d33 6665                467_000339a0-3fe
0x0160 3439 3434 380d 0a54 6f3a 203c 7465 6c3a                49448..To:.<tel:
0x0170 2b31 3430 3437 3830 3838 3938 3e0d 0a41                +14047808898>..A

Hi Tod,
The "session target registrar " point to the SIP-TRUNK to the PSTN, as detailed exaplaination:
session target (VoIP dial peer)
To designate a network-specific address to receive calls from a VoIP or VoIPv6 dial peer, use the session target command in dial peer configuration mode. To reset to the default, use the no form of this command.
A ideal situation would be to use session target ipv4: of the ITSP:
dial-peer voice 105 voip
description **Outgoing Call to SIP Trunk**
translation-profile outgoing PSTN_Outgoing
destination-pattern 91%...........
session protocol sipv2
session target ipv4:11.11.11.11:6034 <<(1st SIP-TRUNK)
voice-class codec 2
dtmf-relay rtp-nte
no vad
dial-peer voice 106 voip
description **Outgoing 2ND Call to SIP Trunk**
translation-profile outgoing PSTN_Outgoing
destination-pattern 91%...........
session protocol sipv2
session target ipv4:22.22.22.22:6035 <<(2ND SIP-TRUNK)
voice-class codec 2
dtmf-relay rtp-nte
no vad
Rate the post accordingly.
Regards,
Kevin

Invitation Error: Only the Organizer can change this event

After doing a clean install of Snow Leopard on my MacBook Pro, I was getting the following error when trying to edit some iCal events:
Invitation Error: Only the Organizer can change this event
The iCal events that I couldn't edit had all been ones where I had sent invitations to someone else. When I double clicked them to attempt to edit them, I received a popup that would allow me to accept/decline the event, but not edit it. I noticed in the popup that it had the email address of the original invitee plus my own email address. I'm sure that my own email address wasn't there before.
I took a look at "My Card" in address book and it only had my name and no email addresses.
After the install I had synced iCal and Address Book with MobileMe. The sync said there was a conflict with my Address Book entry and I accepted the one from MobileMe, thinking I hadn't put anything in the one on my laptop yet anyway. I ended up with the original of my Address book entry, but not marked as "my card" and an entry with just my name marked as "my card".
When I merged the two cards and made sure the resulting card was marked as my card, I could then edit the iCal events. I think it was the fact that "my card" now had my MobileMe / .Mac email address in it that allowed me to edit the iCal events.
So if you're having this problem editing events, check your My Card in Address Book and make sure it has the appropriate email addresses in it.
- David
PS - There was an earlier post with this topic, but it didn't mention this solution. I would've replied to that post but it had been archived and replies were not allowed.

I have found a way around this. If you drag the event to your desktop, it will create an .ics file. If you open this file in TextEdit, you can delete the line that begins with ORGANIZER:. Save the file and bring it back into iCal. iCal will now assume you are the organizer, allowing you to edit. You may also want to delete the other attendees in TextEdit, as iCal will also want to send updates if you make changes to the file (because it thinks you're the organizer making changes to your own calendar event).
This isn't an ideal solution, but it lets you make the edits. Hopefully Apple will change this in a future Leopard update or in Snow Leopard.

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!

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.

Set Domain in SIP INVITE

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
Gunnar

Hi, 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

SIP INVITE

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 Krishnan

As 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 ...

SIP Invite Message

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!
Jon

Sorry, I found solution.

SIP invite error on UC520

Similar Messages

Maybe you are looking for