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
Similar Messages
-
Lync Federation - Accept SIP Reverse Negotiation (SIP Invite without SDP)
Hello,
Recently I tested a SIP Federation trunk between Lync Server 2013 and non-Lync Client.
In this scenario the Lync Client 2013 support SIP Reverse Negotiation, by other words if SIP Invite without SDP it's sent to Lync Client 2013 it will be accepted by any configuration option?
With the default settings seams that it's not supported with error reason "Error parsing body"
Trace-Correlation-Id: 3549384327
Instance-Id: 4C9
Direction: outgoing
Peer: lynctest.domain.com:2138
Message-Type: response
Start-Line: SIP/2.0 488 Not Acceptable Here
From: "User4" <sip:[email protected]>;tag=3794445243
To: <sip:[email protected]>;epid=abad235729;tag=a130a7e357
Call-ID: [email protected]
CSeq: 12784624 INVITE
Via: SIP/2.0/TLS 172.16.3.51:5065;branch=z9hG4bK-5765F571;rport;alias;received=172.16.3.51;ms-received-port=2138;ms-received-cid=1200
Content-Length: 0
ms-client-diagnostics: 52009;reason="Error parsing body"
Regards,
ClaudioHello All,
After some analysis I got the following conclusions.
Lync PC Client doesn't accept initial Invite without SDP ( Delayed Offer ).
However our goal was to test the SIP Reverse Media Negotiation mechanism, so we sent initially a dummy SDP for the initial invite and after the connect send a SIP INVITE without SDP and for my surprise the Lync Client accepted and sent his own SDP on the
200 OK and we sent the new SDP offer in the ACK.
However the result was no Audio, and Lync Client kept sending the Audio to the initial INVITE SDP and ignored the new SDP offered in the ACK message.
So my conclusion it's that LYNC Client doesn't support SIP Reverse Media Negotiation (Delayed Offer) at all since it ignores the new SDP offered in the ACK message for the mid call media renegotiation attempt with SIP INVITE without SDP.
Traces:
INVITE sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="F5054EF3", snum="104", rspauth="040401ffffffffff0000000000000000e9693240576b479326af5617", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 56
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Contact: <sip:[email protected]:5065;transport=TLS>
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 0
Require: 100rel
Supported: 100rel,replaces,privacy,timer,from-change,histinfo,answermode
User-Agent: (Virtual Appliance)
P-Asserted-Identity: "" <sip:[email protected]>
Session-Expires: 720;refresher=uac
P-Sig-Options: Sending-Complete
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="785246a1", cnum="92", response="040400ffffffffff000000000000000000b60640ac2c60c49bc1b427"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Contact: <sip:[email protected];opaque=user:epid:wc5Y6-kDo16CxuVbyxqk9gAA;gruu>
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-dialog-route-set-update
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="e903d142", cnum="93", response="040400ffffffffff0000000000000000dbe0e9524a1031ef81a19d2f"
Content-Type: application/sdp
Content-Length: 354
v=0
o=- 0 1 IN IP4 172.16.1.87
s=session
c=IN IP4 172.16.1.87
b=CT:99980
t=0 0
m=audio 12530 RTP/SAVP 8 0 13 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:mIMHiJBpn4ZRZfg2VXYSTdQfS4wyJ0x57QQ0q4kU|2^31
a=maxptime:200
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
ACK sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK301D467E.2E943CC97CBC4CCD;branched=FALSE
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CEE;rport;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="B8AB5336", snum="105", rspauth="040401ffffffffff0000000000000000de85d6c7415302c9b7535777", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 69
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 ACK
Contact: <sip:[email protected]:5065;transport=TLS>
Content-Length: 326
Content-Type: application/sdp
v=0
o=- 262 2 IN IP4 172.16.13.192
s=session
t=0 0
m=audio 16392 RTP/SAVP 8 101 13
c=IN IP4 172.16.13.191
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:X0rDwl9KxCJfSsRaX0rEkl9KxNJfSsUCX0rFOtIK|2^31 -
Lync 2010 client does not offer any NON-direct UDP Candidates in its SIP Invite' SDP - why?
Hello.
We have a customer, experiencing the following issue.
They have big multi-continental Lync Server 2010 Enterprise Edition deployment, with non-NAT'ted Edge Pool.
The call scenario is simple: peer-to-peer video (A/V) call between external Lync client and Video system, Cisco VCS
in this case but does not matter, which (video system) only supports media over UDP (which is nothing strange). The VCS has a lot of video endpoints all over the Globe, Lync clients are also everywhere, so call can be any "distance", not predictable.
All video endpoints are registered on this single VCS.
The video call, as I suspect, only succeeds IF direct peer-to-peer UDP connection works and fails otherwise.
I skip the overall design, keeping here only what is relevant.
Video system offers only its own local IP as UDP candidate (type = host), which in this particular
case is expected, let's assume there is no TURN etc expected on video system' side, it is directly Internet-facing.
Now the main bit. Lync client offers ALL proper TCP candidates: both local AND non-local, using external
public IP addresses of both A/V Edge Hardware LoadBalancer VIP and public IP address of one of Edge servers.
Those candidates are enlisted perfectly fine (I checked carefully), so SIP INVITE has them all offered.
Now: the Lync 2010 client ONLY offers direct/local UDP candidate (type = host) with its own IP address,
but does NOT offer any NON-local UDP Candidates at all (while, again, for TCP candidates the full set of non-local (A/V Edge) ones is offered).
WHY this can happen?
Again my guess on where to dig is: TCP candidates (which are completely useless for such video call)
are all offered fine with A/V Edge's public IPs, both VIP and particular node ones. Does this fact make sense?
WHAT can be the reason why the same or similar remote/Edge Candidates are not being
offered/enlisted for UDP while for TCP they are offered?
What I already found, to be excluded easily: the whole client sign-in and in-band provisioning is OK, all about
certificates is Ok, and all about MRAS URI and MRAS Credentials (looking sign-in traces) is also fine. Client gets proper MRAS username/password and ALL about signaling before SDP is also fine (no TLS or MRAS related errors).
I cannot rule-out potential DNS issues at the moment, however unlikely: otherwise how it would get proper list
of NON-local TCP candidates and all SIP signalling with the Edge working Ok if it would be DNS-specific issue?
What, however, I have not confirmed is: UDP port 3478 is most likely NOT opened on/between all of the involved parties (Edge's private and public interfaces, Hardware LoadBalancer's interfaces and client),
and/or UDP 3478 communication is most likely getting blocked completely (when the client is external), however for instance TCP 443 is everywhere opened.
Can THIS be somehow related to why it properly allocates non-local TCP but none of
non-local UDP Candidates?
What traces show on call negotiation is ICE Connectivity Failed and/or ICE Warning - I have real it carefully, did WireShark'ing, what I suspect is: simply ICE Connectivity Checks fails on direct P2P UDP which is of course expected, and because no non-local
UDP candidates are offered and TCP is not allowed on video system' side - it fails. WireShark shows the following: millions of outgoing UDP from the client to Cisco VCS and not even one INcoming UDP back from VCS.
Sometimes, depending on the external client's location, call, however, succeeds. I guess (guess)
this is because SOMETIMES direct UDP flows Ok, while in vast majority of the cases it expectedly does not.
Big thanks.
/roubchiHi,
VideoendpointsonlysupportUDPmedia.ICEusuallyoffers3candidates: Host(privateIP), ServerReflexive(outsideIPaddressoffirewalllocaltothemediasupplyingagent–B2BUAorLyncClient),
TURNserver(typicallytheEdgeServer/VCSExpressway)
You can refer to the link of “Cisco
VCS and Microsoft Lync Deployment Guide (X8.1)” to check the configuration of Lync integrated with Cisco VCS.
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support -
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! -
Am setting up a SIP trunk on a UC520. Outbound calling is working fine. Inbound is not.
The SIP invite comes in but is rejected with a: SPI_validate_own_ip_addr: ReqLine IP addr
does not match with host IP addr
I suspect this is caused by the fact that the invite is using the sender IP and not my (recipient IP)
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
As a way to test, I created a tunnel interface with the 208.65.240.44 address, and the call rings through.
The question is, Is there a way to disable SPI validation on a UC520, as i doubt I can get the SIP provider to fix their Invite string?Am setting up a SIP trunk on a UC520. Outbound calling is working fine. Inbound is not.
The SIP invite comes in but is rejected with a: SPI_validate_own_ip_addr: ReqLine IP addr
does not match with host IP addr
I suspect this is caused by the fact that the invite is using the sender IP and not my (recipient IP)
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
As a way to test, I created a tunnel interface with the 208.65.240.44 address, and the call rings through.
The question is, Is there a way to disable SPI validation on a UC520, as i doubt I can get the SIP provider to fix their Invite string? -
Modify calling number in SIP invite on CUCM 10.5
Hello,
I am working at a customer with CUCM 10.5 who uses MGCP gateways to access the PSTN via T1 PRI ISDN.
They use four digit DNs internally and need to prefix these with 713657 to make the outbound CLID work ok - i.e. a call to the PSTN from extension 1000 needs to send 7136571000 to the ISDN provider.
I configured this using Calling Party Transformations and this works fine e.g.
A Calling Party Transformation for 1XXX would prefix 713657.
The problem I have is that the customer has a NICE active recording system which communicates with the CUCM cluster using a SIP trunk.
The invites that CUCM sends via the SIP trunk show the full ten digits rather than the four digit extension which will not work according to company deploying the recording system.
If I remove the Calling Party Transformation then the SIP invite shows four digits and the call recording works but the outbound CLID does not work.
Can anyone suggest a way to fix this? The customer does not want to change the gateway protocol from MGCP to H323 which would be my favoured choice. Any change of calling party setting on CUCM (e.g. ticking the use external mask for calling party on route pattern) affects the SIP invite.
Ideally I need a way to modify the number in the SIP invite but I cannot find any example of how to do this.
Any suggestions are welcome.
ThanksHi, thanks for your response.
The Calling Party Transformation CSS is not applied to the SIP trunk but is applied to the T1 port of the MGCP gateway.
The Transformations are still applied to the SIP Invite messages via the trunk so I guess this is a quirk of the calling recording profile setup on CUCM.
I did try creating another Calling Party Transformation setup which stripped the unwanted digits and applied it to the SIP trunk but it had no effect. -
Hi!
I recently took over management of a Windows 2003 domain that had only one domain controller. I was building a second DC for redundancy and discovered that the SYSVOL share on the original DC is in "JRNL_WRAP_ERROR" after the SYSVOL and NETLOGON
share would not create on the new DC. This error goes back as far as the log goes back so I don't know how long it has been in this state.
The message in the event log states to enable "Enable Journal Wrap Automatic Restore" but I found a KB article that says to use the BurFlags key instead. http://support.microsoft.com/kb/290762
Should I run an authoritative restore since I don't have another domain controller with a good SYSVOL?
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\windows\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.
[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication
Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.
To change this registry parameter, run regedit.
Click on Start, Run and type regedit.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.
If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.> The message in the event log states to enable "Enable Journal Wrap
> Automatic Restore" but I found a KB article that says to use the
> BurFlags key instead.
http://support.microsoft.com/kb/290762
>
> Should I run an authoritative restore since I don't have another domain
> controller with a good SYSVOL?
The automatic restore process AFAIK will initiate a D2 restore. And if
there's no other DC, sysvol might be gone.
I really would prefer to have control - this means I would do a D4.
Absolutely I would :)
Martin
Mal ein
GUTES Buch über GPOs lesen?
NO THEY ARE NOT EVIL, if you know what you are doing:
Good or bad GPOs?
And if IT bothers me - coke bottle design refreshment :)) -
Get '500 Internal Server Error' during SIP INVITE - cause 44
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Get ‘500 Internal Server Error’ during SIP INVITE - cause 44
Have you ever seen anything like this before? It usually works, but intermittently, we see calls get rejected. It somehow seems related to high loads on the router. We reduced the occurrences by changing our code to throttle the number of SIP INVITEs we send, but this doesn’t scale well. Once it occurs, the only way to clean it up is to do a shut/no shut on the voice-port associated to SIP INVITE.
Any suggestions on how we can proceed to debug this issue?
BACKGROUND:
Cisco 2811 running (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)
NAME: "2811 chassis", DESCR: "2811 chassis" PID: CISCO2811
NAME: "9 Port FE Switch on Slot 0 SubSlot 1", DESCR: "9 Port FE Switch" PID: HWIC-D-9ESW
NAME: "WIC/VIC/HWIC 1 Power Daughter Card", DESCR: "9-Port HWIC-ESW Power Daughter Card" PID: ILPM-8
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 2", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "Two port E1 voice interface daughtercard on Slot 0 SubSlot 3", DESCR: "Two port E1 voice interface daughtercard" PID: VWIC-2MFT-E1=
NAME: "PVDMII DSP SIMM with four DSPs on Slot 0 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "High Density Voice2 Network module with on board two port interface on Slot 1", DESCR: "High Density Voice2 Network module with on board two port interface " PID: NM-HDV2-2T1/E1
NAME: "2nd generation two port EM voice interface daughtercard on Slot 1 SubSlot 0", DESCR: "2nd generation two port EM voice interface daughtercard" PID: VIC2-2E/M
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 2", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 3", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
NAME: "PVDMII DSP SIMM with four DSPs on Slot 1 SubSlot 5", DESCR: "PVDMII DSP SIMM with four DSPs" PID: PVDM2-64
WIRESHARK:
No. Time Source Destination Protocol Info
2 0.057246 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 2 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
3 0.071428 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 3 (1109 bytes on wire, 1109 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
4 0.089917 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 4 (1116 bytes on wire, 1116 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41a-100875-517454db
From: <sip:[email protected]:5060>;tag=82f4a00-9c7344ab-13c4-45026-41a-4ea64c5a-41a
To: <sip:[email protected]:5060>;tag=48645D8-1175
Date: Wed, 08 Sep 2010 20:47:49 GMT
Call-ID: 80e4f50-9c7344ab-13c4-45026-41a-10aff3f4-41a
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 8759 6996 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 8759
Session Version: 6996
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 18710 RTP/AVP 18 101
Media Type: audio
Media Port: 18710
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
7 1.661867 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 7 (469 bytes on wire, 469 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
8 1.676056 10.194.154.136 171.68.115.156 SIP/SDP Status: 183 Session Progress, with session description
Frame 8 (1107 bytes on wire, 1107 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 183 Session Progress
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
10 1.700567 10.194.154.136 171.68.115.156 SIP Status: 100 Trying
Frame 10 (471 bytes on wire, 471 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
No. Time Source Destination Protocol Info
11 1.726376 10.194.154.136 171.68.115.156 SIP/SDP Status: 200 OK, with session description
Frame 11 (1114 bytes on wire, 1114 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100eca-13593e22
From: <sip:[email protected]:5060>;tag=82f4b98-9c7344ab-13c4-45026-41c-669825d-41c
To: <sip:[email protected]:5060>;tag=4864C1C-10F8
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5138-9c7344ab-13c4-45026-41c-3f6bfc7-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (Remote-Party-ID)]
[Message: Unrecognised SIP header (Remote-Party-ID)]
[Severity level: Note]
[Group: Undecoded]
Contact: <sip:[email protected]:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 264
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsSIP-GW-UserAgent 7991 6854 IN IP4 10.194.154.136
Owner Username: CiscoSystemsSIP-GW-UserAgent
Session ID: 7991
Session Version: 6854
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.194.154.136
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17660 RTP/AVP 18 101
Media Type: audio
Media Port: 17660
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Connection Information (c): IN IP4 10.194.154.136
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.194.154.136
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
No. Time Source Destination Protocol Info
13 1.727645 10.194.154.136 171.68.115.156 SIP Status: 500 Internal Server Error
Frame 13 (526 bytes on wire, 526 bytes captured)
Ethernet II, Src: Cisco_0d:3c:c0 (00:1f:ca:0d:3c:c0), Dst: HewlettP_06:71:52 (00:1f:29:06:71:52)
Internet Protocol, Src: 10.194.154.136 (10.194.154.136), Dst: 171.68.115.156 (171.68.115.156)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 500 Internal Server Error
Message Header
Via: SIP/2.0/UDP 171.68.115.156:5060;rport;branch=z9hG4bK-41c-100f04-2fde97a9
From: <sip:[email protected]:5060>;tag=82f4d30-9c7344ab-13c4-45026-41c-5c20b753-41c
To: <sip:[email protected]:5060>;tag=4864C50-3C3
Date: Wed, 08 Sep 2010 20:47:51 GMT
Call-ID: 80e5320-9c7344ab-13c4-45026-41c-7fbe4865-41c
CSeq: 1 INVITE
Sequence Number: 1
Method: INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=44
Reason Protocols: Q.850
Cause: 44(0x2c)[Requested circuit/channel not available]
Content-Length: 0
Thanks!
-JohnSince it appears you are a Cisco Employee, my recommendation is that you use the many internal resource available to you (including, but not limited to) , like TAC access, internal forums, team leaders, etc.
This not to give the casual reader, the impression that the best source of support at Cisco is a customer's public forum. -
SIP Invite change for anonymous calls
I noticed a change in IOS Gateways in how it deals with anonymous calls. Anonymous calls in version 12.4(25g) generates an SIP INVITE:
From: "anonymous" <sip:[email protected]>
A anonymous calls on version 15.1(4)M8 generates a SIP INVITE:
From: "anonymous" <sip:[email protected]>
The p-asserted-identity and remote-party-id did not change. None of our other SIP systems use the "anonymous@" format.
How do I get the 15.1 GW to use "<number>@" instead of "anonymous@" for these calls?
Thanks,
-JohnHi John,
The only possible solution that i could think of for this scenario is through the use of SIP profiles on the gateway. There are quite a few posts and docs which you can check to try and configure one for your setup
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/105624-cube-sip-normalization.html
http://www.gossamer-threads.com/lists/cisco/voip/127376
HTH
Manish -
We had a major storm over the weekend which caused an unexpected shutdown.
I am having an issue with one of my domain controller with Event ID 13568
The domain controller which is running Windows Server 2012 was added successfully just a couple of days ago.
I do not have a full backup of the server yet.
It only has a GC role on it.
What are the things I should look out for before I attempt to Enable Journal Wrap Automatic Restore and set it to 1?
Would it be safer to just demote the server and start from scratch?
Thank you all for reading!
Mladen
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\windows\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.
[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this
error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs"
followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from
making the data unexpectedly unavailable if this error condition occurs again.
To change this registry parameter, run regedit.
Click on Start, Run and type regedit.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.
If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.I set Enable Journal Wrap Automatic Restore to 1 and it was
successful.
I will monitor it to make sure it does not occur again.
Thanks everyone on your replies
Mladen -
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>..AHi 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 -
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.
-
Good morning,
Please, could you kindly help me with the following matter?
I have some questions regarding how CUCM builds some fields in a SIP INVITE message. Last week I was reviewing logs and I found the below R-URI when an extension calls another extension:
A number--> 7100 ---(1 SIP invite) ----> CUCM ---- (2 SIP invite) ----> B number 7101
1 SIP invite R-URI: sip:[email protected]; user=phone
2 SIP invite R-URI: sip:[email protected]:51544;transport=tcp where
5ea27f5e-033b-880c-e304-0729574bfb1 is the user part.
I thought the first invite should be sip:[email protected]; user=phone. Concerning the invite from CUCM to B number, how does CUCM build the user part from the B number?
Moreover, what are Contact ang tag fields used for in a sip message? how does CUCM build them?
Thanks in advance.
Juan.Juan,
I will explain how a sip phone signals to CUCM when making a call...Two major things happen
1. The first digit dialled is sent in the INVITE
2. The remaining digits are sent via NOTIFY (in the NOTIFY, you will see the digits that are dialled
The trace below details what happens when a sip phone makes a call. I stopped this trace after digit=8 was dialled
Called number=918772888362
Here we get INVITE with SDP from the sip phone to CUCM
29/2010 10:36:33.771 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 1717 bytes:
INVITE sip:[email protected];user=phone SIP/2.0 (first digit dialled =9)
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Call-ID: [email protected]
Max-Forwards: 70
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP9951/9.0.1
Contact:
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Test User 1" ;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,Xcisco-
service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-5.0.0,X-cisco-xsi-9.0.1
Allow-Events: kpml,dialog
Content-Length: 632
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 26964 0 IN IP4 172.18.159.152
s=SIP Call
t=0 0
m=audio 29254 RTP/SAVP 0 8 18 102 9 116 124 101
c=IN IP4 172.18.159.152
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:9 G722/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:124 ISAC/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 25466 RTP/AVP 97
c=IN IP4 172.18.159.152
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E
a=recvonly
+++Next CUCM sends trying++++
03/29/2010 10:36:33.773 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port
51682 index 2321
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1636ab61
From: "Test User 1" ;tag=00260bd9669e07147bcb3aac-3cda8f0c
To:
Date: Mon, 29 Mar 2010 14:36:33 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
+++++Unified CM Sends a REFER to play Outside Dialtone++++
03/29/2010 10:36:33.780 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 409
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
DtOutsideDialTone
user
++++Unified CM Sends a SUBSCRIBE for KPML++++
03/29/2010 10:36:33.781 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682 index 2321
SUBSCRIBE sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To:
Call-ID: [email protected]
CSeq: 101 SUBSCRIBE
Date: Mon, 29 Mar 2010 14:36:33 GMT
User-Agent: Cisco-CUCM8.0
Event: kpml; [email protected]; from-tag=00260bd9669e07147bcb3aac-3cda8f0c
Expires: 7200
Contact:
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 424
<?xml version="1.0" encoding="UTF-8" ?>
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">
[x#*+]|bs
++++ Phone Sends 200 OK for the REFER and SUBSCRIBE ++++
03/29/2010 10:36:33.802 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port 51682 index 2321 with 453
bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151511c5f04bf
From: ;tag=2144536187
To: ;tag=00260bd9669e07167c743311-343ee3af
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
Phone Sends 200 OK for the REFER and SUBSCRIBE
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
03/29/2010 10:36:33.843 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 465 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK1515232b4e84f
From: ;tag=1976165806
To: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 SUBSCRIBE
Server: Cisco-CP9951/9.0.1
Contact:
Expires: 7200
Content-Length: 0
Unified CM Sends a SUBSCRIBE for KPML
220
++++User Dials a ‘1’, phone sends a NOTIFY to CUCM for the digit++++
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 1001 NOTIFY
Event: kpml
Subscription-State: active; expires=7200
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="1" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK++++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
++++Unified CM Replies Sends a REFER to Disable Outside Dialtone+++
03/29/2010 10:36:34.353 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
REFER sip:[email protected]:51682 SIP/2.0
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To:
Call-ID: [email protected]
CSeq: 101 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-CUCM8.0
Expires: 0
Refer-To: cid:[email protected]
Content-Id: <[email protected]>
Require: norefersub
Content-Type: application/x-cisco-remotecc-request+xml
Referred-By:
Content-Length: 401
[email protected]
97903bc0-a3de-4a15-ba27-44c81fe3adcd-45510542
00260bd9669e07147bcb3aac-3cda8f0c
Dt_NoTone
user
+++Phone Replies With 200 OK to REFER++++
03/29/2010 10:36:34.402 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 453 bytes:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.106.59:5061;branch=z9hG4bK151536ea86ab0
From: ;tag=1574166193
To: ;tag=00260bd9669e07184b08b96b-796ab86f
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:33 GMT
CSeq: 101 REFER
Server: Cisco-CP9951/9.0.1
Contact:
Content-Length: 0
++++User Dials a ‘8’, phone sends a NOTIFY to CUCM+++
03/29/2010 10:36:34.944 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 172.18.159.152 on port
51682 index 2321 with 896 bytes:
NOTIFY sip:[email protected]:5061 SIP/2.0
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK647d03c1
To: ;tag=1976165806
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
Call-ID: [email protected]
Date: Mon, 29 Mar 2010 14:36:34 GMT
CSeq: 1002 NOTIFY
Event: kpml
Subscription-State: active; expires=7195
Max-Forwards: 70
Contact:
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 209
Content-Type: application/kpml-response+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
forced_flush="false" digits="8" tag="Backspace OK"/>
+++Unified CM Replies to NOTIFY With a 200 OK+++
03/29/2010 10:36:34.352 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 172.18.159.152 on port 51682
index 2321
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.18.159.152:51682;branch=z9hG4bK1cd529ba
From: ;tag=00260bd9669e07177ee0d51d-14f56f89
To: ;tag=1976165806
Date: Mon, 29 Mar 2010 14:36:34 GMT
Call-ID: [email protected]
CSeq: 1001 NOTIFY
Content-Length: 0
As you can see this is similar to what you are seeing...The first digit dialled is seen in the INVITE, the remaining digits will be seen in NOTIFY.
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared" -
SPA303 - Reordering the position of Content-Length header in SIP INVITE
Hi,
I have SPA303 IP Phone connected behind a SIP ALG router but have been facing issues with media setup for incoming and outgoing calls.
Further investigation using SIPp script helped me out to understand the root cause of the issue which is as follows:
If the SIP INVITE or 200 OK for SIP INVITE has Content-Length header ahead of the Content-Type header, the SIP ALG router is not able to handle the RTP traffic for the calls. Cisco SPA303 IP phone exhibits this behaviour and hence couldn't successfully establish call with the SIP ALG that I use.
Can you please confirm if it is configurable to reposition or re-order the Content-Length header to resolve this issue?
Thanks in advance.
Regards,
Anand KrishnanAs far as I know it's not configurable. According SIP protocol, the order of SIP headers is not meaningfull.
Your router need to accept both orders as both are corrrect and have same meaning. Ask the vendor of router for updated firmware ... -
Hello,
How can be configured the CCA that in SIP Invite Request in FROM section of Message Header instead of "sip:system@.... " sip:00061007@...", where 00061007 is the line number?
Thanks for help!
JonSorry, I found solution.
Maybe you are looking for
-
A lot of recent problems, please help
Let's go back to a month ago to start. Turned on my computer, had an X appear where the apple should have been, reinstalled leopard, erased my hard drive completely. Worked fine until two weeks ago when I got stuck at a solid blue screen at startup.
-
How do you edit-in a "stop" into a screen recording and then insert a "button" to link to a document
Ok, so I am working on my first Captivate project. So far so good (mostly). I want to interupt a screen capture recording that I now have. Currently, it captures a pdf screen and an audio narration. I want to have a button appear at a certain tim
-
PO not created automatically after creation and approval of SC
Hi all, We are using SRM7.0 Extended Classic Scenario. We are able to create Shopping Cart successfully. For items where a source of supply is not supplied, the Shopping Cart goes through the approval process and then into the sourcing Cockpit. But f
-
How do I get these podcasts onto Itunes???
http://www.packerchatters.com/home/index.php?option=com_content&task=view&id=706 &Itemid=2 There is a way to get these onto iTunes but I don't know how to do it... Can anyone help me? Thanks
-
SoundBlaster 5.1 VX and Windows7 Bass redirection
Hi, i have a SoundBlaster 5. VX and an analog 5. surround system. My OS is Windows 7 final. I can't get my subwoofer to work. I set my speakers to 5., tested them and every speaker including the subwoofer works. But when i try to play music in window