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

Similar Messages

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

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

My ringer is no longer working for text and email notifications. Only working for phone calls. I have gone through all the settings to see where something is off. Not finding anything. I have tried changing the tone and it just vibrates on everything.

My ringer is no longer working for text and email notifications. Only working for phone calls. I have gone through all the settings to see where something is off. Not finding anything. I have tried changing the tone and it just vibrates on everything.

Ok so I happened to figure it out while on the phone to apple support. Even though the guy was very nice, I think I knew more than him! He was explaining very basic resolution principles I played about. I had the second option in displays resolution. All I did was unplug the HDMI cable, click on 'best for display' then plugged the HDMI in and my resolution on the normal monitor changed to the normal blue, then went black momentarily and then changed to a strange resolution but another window appeared that said SONY BRAVIA HDMI at the top! Hey presto! Don't know why it didn't do it yesterday - I probably left the HDMI cable in or something! Oh well. Problem solved!

How do I change my incoming calls to view caller's phone number instead of name? This is for numbers not stored in my contacts (i.e. Unknown)

How do I change my incoming call view to see the "phone number" instead of seeing "Unknown" for contacts who are not stored in my phone? Whenever a call comes in it says unknow instead on the phone number that is calling.

You need to set up the accounts in System Preferences/Accounts, then activate Fast User Switching.
That way you can quickly log in to your own account - then back to his.
You should obviously have different passwords.

RFC Adapter Receiver - change SAP User for each call

Hi guys,
I need to create one connection between PI and SAP, all right, i can use RFC Adapter Receiver, no problem.
But, for each call i need to use User and Password different, then, I would pass SAP User and Password in my XML Payload.
Can anybody help me, please?

hi,
>>But, for each call i need to use User and Password different, then, I would pass SAP User and Password in my XML Payload.
sure we can help you but no in this way:)
it is possible to change the user for RFC adapter but using
principal propagation:
/people/alexander.bundschuh/blog/2007/01/16/principal-propagation-in-sap-xi
this is the way you need to go and not send password in XML payload
(this is certainly not the way and no client will approve it)
why use a password is anyone can see it ?
Regards,
Michal Krawczyk

Where can I change desktop for anonymous user ?

Hello.
Where can I change desktop for anonymous user ? I'd like to change it in the same manner as sampleportal desktop (with amconsole) , but I did not found it in the amconsole.
If you know, please, tell.

The user "authlessanonymous" holds the information that people see if they are not signed on. It can be changed like any other user. It may have to be enabled under the Service Configuration tab -> portal desktop.

CUCM: Third Party SIP Phone "Caller ID" is not displaying for outgoing calls

Hi Team,
we are running CUCM 9.1(2a),
we have integrated Third Party SIP Phone(Avaya 1230 SIP Phone) with CUCM,
Issue: Third Party SIP Phone "Caller ID" is not displaying for outgoing calls, we are able to see only the dailed Number,
When "A" calls to "B", "A" can see only the dailed number of "B" but not the "Caller ID"
Regards
Ananthakumar

Are A and B both Avaya phones?
So it looks like you're not seeing the alerting name/connected name getting updated then? Do you have alerting names configured on the directory numbers? Might need to take a look at the SIP messaging to see if the alerting name/connected name is being sent to the Avaya phones and maybe they just aren't displaying it. Might just be something that needs to be tweaked in the 46xxsettings.txt file.

Change language for the Caller ID announcement

How can I change the Caller ID announcement from English to say German ?
I have installed the German text to speech package and that works as expected for messages text to speech so one would think that can be used for the Caller ID announcement as well.
Any thoughts, help ?
Cheers
chris

Hi MC
In the OP43 transaction (Setup group category-setup group Key SPRo ), select the setup group key for which you want the translation to be maintained, select the GOTO in the menu bar - click on the translation and select the Language for which you want to maintain the translation. Maintain your translated text here.
The other way is to Log in in the language you want to maintain the transaltion Go to OP43 and maintain the details.
You will have to maintain them in SPRO and the same will be reflected for the recipes in the respective login language in the master recipe.
If the solution works for you or is helpful, give suitable points.
Regards,
Amol Kale
Edited by: Amol Kale on Mar 1, 2012 7:09 AM

Changing volume for phone calls.

is there any way to change the volume for phone calls besides the outside volume key?? I tried "sounds" in settings and it did not work.

Your volume switches work differently depending on what you are doing. You may get a readout above the "speaker" symbol that appears on the screen telling you what volume is being adjusted.
If you are not using anything, the volume switches adjust the ringer volume.
If you are playing music or video, they adjust the music/video volume.
If your headphone are plugged in, they adjust the headset volume.
If you are actually on a call, the adjust the earpiece volume or speakerphone volume (without a readout).
If you are on a phone call using bluetooth, they adjust the bluetooth volume.
Dial a recording like the National Time Signal (303) 499-7111 and adjust the volume during the call.

Problem with anonymous caller id in spa8000

Hi,
We have started to migrate our customer from pap2t to spa8000.
Now we got an issue that we need help with.
If we activating CID block (*67) the sip server will deny the INVITE
I think it has to do with from and contact field.
All parts is now anonymous, in pap2t the real number is still in the <>.
Is it possible to change this?
Any Ideas?
My invite looks as following:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5360;branch=z9hG4bK-ff7fa670
From: "Anonymous" <sip:anonymous@localhost>;tag=1fdbc659fb942988o0
To: <sip:[email protected]>
Remote-Party-Id: "33333333333" <sip:[email protected]>;screen=yes;privacy=full;party=calling
Call-Id: 612a4f6d-18571384@localhost
Cseq: 101 INVITE
Max-Forwards: 70
Contact: "Anonymous" <sip:[email protected]:5360>
Expires: 240
User-Agent: Linksys/SPA8000-6.1.12
Allow-Events: talk, hold, conference
Content-Length: 444
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp
Date: Mon, 02 Dec 2013 15:29:48 GMT
with pap2t is look like this:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 3.3.3.3:5061;branch=z9hG4bK-1ff53e0
From: Anonymous <sip:[email protected]>;tag=c0bc166c356c37ffo1
To: <sip:[email protected]>
Call-Id: 8d9cc4b0-68e7be8b@localhost
Cseq: 101 INVITE
Max-Forwards: 70
Contact: Anonymous <sip:[email protected]:5061>
Expires: 240
User-Agent: Linksys/PAP2T-5.1.6(LS)
Content-Length: 438
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp
Date: Mon, 02 Dec 2013 19:01:54 GMT
//N

Just to be sure - do you know you are replacing one end-of-life platform (PAP2T) with another end-of-life device (SPA8000) ?
But back your question.
Your's PAP2T's INVITE has no CLIR active. Caller number is present in both From: and Contact: header, there is no Privacy: Id nor Remote-Party-Id.
So, next-step exchanges know nothing about CLIR and caller's number is transferred to called phone with no restrictions.
On oposite side, SPA8000's invite claim CLIR using Remote-Party-Id method. But your's SIP gateway is rejecting such call.
You either have no right to use CLIR or particular SIP gateway is configured to use other way to request CLIR Remote-Party-Id. Or the CLIR CALL request is rejected somewhere on the path to destination.
Simplest solution ? It seems that CLIR did not worked on your's former network correctly and caller's number has been delivered to called user with no restriction. So disable CLIR service on SPA8000. No functionality will be lost.
Message was edited by: Dan Lukes (SPA8000 is not EOL)

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

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.

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

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

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!

SIP Invite change for anonymous calls

Similar Messages

Maybe you are looking for