<HTML>
<HEAD>
<TITLE>Re: [OpenSIPS-Users] Adtran VQM data into Opensips/CDRTool</TITLE>
</HEAD>
<BODY>
<FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Adrian,<BR>
<BR>
Fantastic information. That would be perfect. Now, I’m wondering if anyone can point me in the right direction towards some scripting logic to properly handle this PUBLISH event and extract the data.<BR>
<BR>
<BR>
Thanks,<BR>
Jeff<BR>
<BR>
<BR>
<BR>
On 2/17/09 4:42 AM, "Adrian Georgescu" <<a href="ag@ag-projects.com">ag@ag-projects.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>If you saved that information CDRTool it will merely display it in the expanded CDR info, nothing more.<BR>
<BR>
Adrian<BR>
<BR>
On Feb 16, 2009, at 10:04 PM, Jeff Pyle wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'> Hello,<BR>
<BR>
We run a number of Adtran TA900-series gateways in our network. Recent software versions have the ability to do voice quality measurements, and output that data at the end of a call through a PUBLISH event. Normally one would configure these devices to talk to an Adtran n-Command MSP data collector.<BR>
<BR>
Because this PUBLISH happens after the call is disconnected, it seems an update would have to occur after the fact, perhaps similar to a Mediaproxy info update. In the example below that Adtran provided to me, the CallID field is ‘unknown’. I’m waiting on a response from Adtran engineering to see if that is always the case. If so, it’s going to be more difficult to match the call.<BR>
<BR>
The following is from the perspective of the Adtran unit:<BR>
<BR>
</SPAN></FONT><SPAN STYLE='font-size:10pt'><FONT FACE="Lucida Console">Tx: TCP src=10.19.209.11:5060 dst=10.100.13.250:5060<BR>
PUBLISH sip:<a href="collector@10.100.13.250">collector@10.100.13.250</a> SIP/2.0<BR>
From: <sip:<a href="LBADTN0816AE392@10.19.209.11">LBADTN0816AE392@10.19.209.11</a>>;tag=4afcca8-0-13c4-3954f-f39d4b80-3954f<BR>
To: <sip:<a href="collector@10.100.13.250">collector@10.100.13.250</a>><BR>
Call-ID: <a href="4afcca8-0-13c4-3954f-e9ebf5f2-3954f@10.19.209.11">4afcca8-0-13c4-3954f-e9ebf5f2-3954f@10.19.209.11</a><BR>
CSeq: 1 PUBLISH<BR>
Via: SIP/2.0/TCP 10.19.209.11:5060;branch=z9hG4bK-3954f-dff3d63-6155485b<BR>
Event: vq-rtcpxr<BR>
Subscription-State: active<BR>
Content-Type: application/vq-rtcpxr<BR>
Content-Length: 1263<BR>
<BR>
VQSessionReport<BR>
LocalMetrics:<BR>
Timestamps:START=2008-12-18T17:55:01Z STOP=2008-12-18T17:55:10Z<BR>
SessionDesc:PT=0 PC=1<BR>
CallID:unknown<BR>
LocalAddr:IP=10.19.209.55 PORT=3004 SSRC=22b4624f<BR>
RemoteAddr:IP=10.19.209.49 PORT=10000 SSRC=22b4624f<BR>
JitterBuffer: JBRSYNC=5 JBP=463 JBPOO=0 JBPD=0 JBPE=37 JBPL=425 JBRC=28 JBENVD=1 JBENVP=0 JBENVPMIN=0 JBENVPM=4 JBENVN=0 JBENVNMIN=0 JBENVNM=0 JBLT=50.0 JBLTP=100.00 JBLUT=11 JBL=11 JBLPJ=2.0 JBET=10.0 JBETP=100.00 JBE=451 JBEPJ=0.0 JBT=1 JBCDMIN=10 JBCDN=50 JBCDM=100 JBDINC=0 JBDDEC=3 JBD=47 JBDI=35 JBDMIN=35 JBDM=50<BR>
PacketLoss:NLR=0.00 JDR=0.00 LR=0.00 JL=0 JD=0 JOD=0 JUD=0<BR>
BurstGapLoss:BLD=0.00 BD=0 GLD=0.00 GD=8640 BPD=0 BC=0 BE=0 GPD=432 GC=1 GE=0<BR>
Delay:RTD=1 ESD=65 OWD=63 IAJ=451 RTDI=1 RTDM=1 ESDMIN=55 ESDM=70 OWDI=58 OWDM=65 LD=0 LDMIN=0 LDM=2 PPDV=0.3 PDV=0 PDVM=2 PDVMN=0.0 PDVMNI=0.4 PDVMNM=0.0 PDVMNAM=2.0<BR>
Signal:<BR>
QualityEst:RLQ=93 RCQ=92 MOSLQ=4.20 MOSCQ=4.18 BRLQ=92 GRLQ=92 RN=93 RG107=92 MOSPQ=4.45 MOSN=4.20 QL=0<BR>
MetricsVersion:MT=ADTRAN MV=01.00<BR>
DeviceSerialNum:LBADTN0816AE392<BR>
CCMID:39<BR>
DSCP:46<BR>
LocalCaller:true<BR>
LocalURI:8249<BR>
LocalIfc:4<BR>
RemoteURI:8884238726<BR>
RemoteIfc:0<BR>
Degradation:DL=0.00 DDISC=0.00 DV=0.00 DR=0.00 DD=0.00 DSL=0.00 DNL=0.00 DEL=1.42<BR>
Data:TI=35000 RI=100 BR=64000<BR>
<BR>
Rx: TCP src=10.100.13.250:5060 dst=10.19.209.11:5060<BR>
SIP/2.0 200 Ok<BR>
Content-Length: 0<BR>
From: <sip:<a href="LBADTN0816AE392@10.19.209.11">LBADTN0816AE392@10.19.209.11</a>>;tag=4afcca8-0-13c4-3954f-f39d4b80-3954f<BR>
Call-ID: <a href="4afcca8-0-13c4-3954f-e9ebf5f2-3954f@10.19.209.11">4afcca8-0-13c4-3954f-e9ebf5f2-3954f@10.19.209.11</a><BR>
CSeq: 1 PUBLISH<BR>
Via: SIP/2.0/TCP 10.19.209.11:5060;branch=z9hG4bK-3954f-dff3d63-6155485b<BR>
To: <sip:<a href="collector@10.100.13.250">collector@10.100.13.250</a>>;tag=482617583<BR>
Allow: OPTIONS, PUBLISH<BR>
Allow-Events: vq-rtcpxr<BR>
SIP-ETag: 1229622954690.781<BR>
Expires: 0<BR>
<BR>
</FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"> First real question: what’s the best way to get the “VQSessionReport” data out of this packet? Some of the data is useful (particularly the MOSPQ value on the QualityEst line), much of it is not. Unfortunately I don’t know anything about the normal uses for PUBLISH.<BR>
<BR>
Assuming one can extract this useful information from this and match it to an existing call in radius and push the useful information into the RTPStatistics field, what would CDRTool do with it?<BR>
<BR>
<BR>
Thanks,<BR>
Jeff <BR>
_______________________________________________<BR>
Users mailing list<BR>
<a href="Users@lists.opensips.org">Users@lists.opensips.org</a><BR>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE='font-size:10pt'><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><BR>
<BR>
</FONT></SPAN></BLOCKQUOTE>
</BODY>
</HTML>