Dale wrote: >Subject: [sipX-dev] (XX-4748) CDR: Call legs that belong to >the same callshould be identifyable so that they can be >grouped in a report > >This message is to describe an attack on the problem of >grouping transferred calls in regard to CDR. This proposal is >to use a "References" header in the INVITE that establishes >the latter, transferred dialog to show that it was derived >from the first, original dialog. > >Here are some more details: > > >We are working on popularizing the following mechanism: When >one dialog is related to another dialog in some way, the >INVITE that establishes the new dialog contains a "References" >header that gives the Call-Id of the old dialog. Thus message >logs will record the connection between the two dialogs. > >In the case of a blind transfer, the new INVITE will look >something like this: > > INVITE sips:[email protected] SIP/2.0 >>>> References: [email protected];rel=refer > Via: SIP/2.0/TLS client.biloxi.example.com:5061 > ;branch=z9hG4bKnashds1 > Max-Forwards: 70 > From: Bob <sips:[email protected]>;tag=8675309 > To: Carol <sips:[email protected]> > Call-ID: [email protected] > CSeq: 1 INVITE > Contact: <sips:[email protected]> > Referred-By: <[email protected]> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY > Supported: replaces > Content-Type: application/sdp > >The marked References header shows that this INVITE was >generated due to a REFER that was received within the dialog >with Call-Id "[email protected]". > >Because SIP elements ignore headers whose names they do not >know, this is upward-compatible. We have implemented >References in a few places in the sipXecs stack and have had >no interoperation problems with any other SIP elements. > >The Internet-Draft that defines References is available at >http://tools.ietf.org/html/draft-worley-references-03. The >example involving REFER is in section 3.2. > > >In a perfect world, the UA that receives the REFER would add >the References header automatically. But of course, it >doesn't. But we can instruct it to do so by modifying the >Refer-To URI in the REFER: > > REFER sips:[email protected] SIP/2.0 > Via: SIP/2.0/TLS client.biloxi.example.com:5061 > ;branch=z9hG4bKnashds8 > Max-Forwards: 70 > From: Alice <sips:[email protected]>;tag=1234567 > To: Bob <sips:[email protected]>;tag=314159 > Call-ID: [email protected] > CSeq: 101 REFER >>>> Refer-To: >>>> ><sips:[email protected]?references=12345601%40atlanta.exampl >>>> e.com%3brel%3drefer> > Referred-By: <[email protected]> > Contact: <sips:[email protected]> > >We already modify the Refer-To headers of REFERs that pass >through the proxy, so we shouldn't have too much difficulty >adding this machinery. > >If there already is a References header-value, we can add our >value to the current value, because the References header >allows multiple values, separated by commas. >
Thanks for the information. I was going to approach it in a similar manner (i.e. adding information to the refer-to) but in a more sipx proprietary fashion but now that I know about the References header, I'll look into using that in the REFER and then extracting it in the INVITE. Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
