[OpenSIPS-Users] Adtran VQM data into Opensips/CDRTool
Jeff Pyle
jpyle at fidelityvoice.com
Tue Feb 17 13:48:44 CET 2009
Adrian,
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.
Thanks,
Jeff
On 2/17/09 4:42 AM, "Adrian Georgescu" <ag at ag-projects.com> wrote:
> If you saved that information CDRTool it will merely display it in the
> expanded CDR info, nothing more.
>
> Adrian
>
> On Feb 16, 2009, at 10:04 PM, Jeff Pyle wrote:
>
>> Hello,
>>
>> 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.
>>
>> 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.
>>
>> The following is from the perspective of the Adtran unit:
>>
>> Tx: TCP src=10.19.209.11:5060 dst=10.100.13.250:5060
>> PUBLISH sip:collector at 10.100.13.250 SIP/2.0
>> From:
>> <sip:LBADTN0816AE392 at 10.19.209.11>;tag=4afcca8-0-13c4-3954f-f39d4b80-3954f
>> To: <sip:collector at 10.100.13.250>
>> Call-ID: 4afcca8-0-13c4-3954f-e9ebf5f2-3954f at 10.19.209.11
>> CSeq: 1 PUBLISH
>> Via: SIP/2.0/TCP 10.19.209.11:5060;branch=z9hG4bK-3954f-dff3d63-6155485b
>> Event: vq-rtcpxr
>> Subscription-State: active
>> Content-Type: application/vq-rtcpxr
>> Content-Length: 1263
>>
>> VQSessionReport
>> LocalMetrics:
>> Timestamps:START=2008-12-18T17:55:01Z STOP=2008-12-18T17:55:10Z
>> SessionDesc:PT=0 PC=1
>> CallID:unknown
>> LocalAddr:IP=10.19.209.55 PORT=3004 SSRC=22b4624f
>> RemoteAddr:IP=10.19.209.49 PORT=10000 SSRC=22b4624f
>> 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
>> PacketLoss:NLR=0.00 JDR=0.00 LR=0.00 JL=0 JD=0 JOD=0 JUD=0
>> BurstGapLoss:BLD=0.00 BD=0 GLD=0.00 GD=8640 BPD=0 BC=0 BE=0 GPD=432 GC=1
>> GE=0
>> 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
>> Signal:
>> 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
>> MetricsVersion:MT=ADTRAN MV=01.00
>> DeviceSerialNum:LBADTN0816AE392
>> CCMID:39
>> DSCP:46
>> LocalCaller:true
>> LocalURI:8249
>> LocalIfc:4
>> RemoteURI:8884238726
>> RemoteIfc:0
>> 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
>> Data:TI=35000 RI=100 BR=64000
>>
>> Rx: TCP src=10.100.13.250:5060 dst=10.19.209.11:5060
>> SIP/2.0 200 Ok
>> Content-Length: 0
>> From:
>> <sip:LBADTN0816AE392 at 10.19.209.11>;tag=4afcca8-0-13c4-3954f-f39d4b80-3954f
>> Call-ID: 4afcca8-0-13c4-3954f-e9ebf5f2-3954f at 10.19.209.11
>> CSeq: 1 PUBLISH
>> Via: SIP/2.0/TCP 10.19.209.11:5060;branch=z9hG4bK-3954f-dff3d63-6155485b
>> To: <sip:collector at 10.100.13.250>;tag=482617583
>> Allow: OPTIONS, PUBLISH
>> Allow-Events: vq-rtcpxr
>> SIP-ETag: 1229622954690.781
>> Expires: 0
>>
>> 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.
>>
>> 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?
>>
>>
>> Thanks,
>> Jeff
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090217/7f1e6e03/attachment-0001.htm
More information about the Users
mailing list