[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