Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 21 May 2004 06:06:40 -0500

QSBtZWNoYW5pc20gZm9yIHJlbGF5aW5nIGNhbGwgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpcyBuZWVkZWQsIGFuZCBJIGFncmVlIHRoYXQgdGhlIGRpdmVyc2lvbiBkcmFmdCBpcyBhIHZpYWJsZSBzb2x1dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcC1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ11PbiBCZWhhbGYgT2YgRGllZ28gQg0KU2VudDogRnJpZGF5LCBNYXkgMjEsIDIwMDQgNDoyOSBBTQ0KVG86IEpvbmF0aGFuIFJvc2VuYmVyZw0KQ2M6IFJveSwgUmFkaGlrYSBSLCBBTEFCUzsgYmFydWNoQGtheW90ZS5jb207IHNheWFuLmNob3dkaHVyeUB3aXByby5jb207DQpzaXBAaWV0Zi5vcmc7IHNpcHBpbmdAaWV0Zi5vcmc7IGZsdWZmeUBjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbU2lwcGluZ10gUkU6IFtTaXBdIFNJUCBGb3J3YXJkLCBXaG8gcGF5cyB0aGUgYmlsbCA/DQoNCg0KSGk7DQoNCkFncmVlZCwgYnV0IG15IGZpcnN0IHF1ZXN0aW9uIHdhcyBleGFjdGx5IHRoYXQsIGlmIHRoZXJlIGlzIGEgc3RhbmRhcmQgDQp3YXkgb3Igc3RhbmRhcmQgSGVhZGVycywgdG8gc3RvcmUgaW5mb3JtYXRpb24gYWJvdXQgYSAiZm9yd2FyZCIgY2FsbC4NCg0KSW4gYSBub3JtYWwgc2l0dWF0aW9uLCBubyBvbmUgd2lsbCB0b3VjaCB0aGUgRnJvbSBoZWFkZXIgYW5kICJub3JtYWxseSINClBTVE4gZ2F0ZXdheSBjb3B5IHRoZSB1c2VyLWluZm8gZnJvbSB0aGUgRnJvbSBTSVAtVVJJIHRvIHRoZSBQU1ROICJCIA0KbnVtYmVyIiwgYW5kIHRoaXMgaXMgbm9ybWFsbHkgdXNlZCB0byBjcmVhdGUgdGhlIENEUi4NCg0KSSdtIG5vdCB0cnlpbmcgdG8gc29sdmUgdGhlIENEUiBjcmVhdGlvbiBpc3N1ZSBvciBob3cgdG8gYmlsbCBhIGZvcndhcmQgDQpjYWxsLCBidXQgSSdtIGxvb2tpbmcgdG8gYSBzdGFuZGFyZCB3YXkgdG8gc3RvcmUgZm9yd2FyZCBpbmZvcm1hdGlvbiBzbyANCm9uZSBkYXkgdGhpcyBpbmZvcm1hdGlvbiB3aWxsIGJlIHVzZWQgY29ycmVjdGx5IHRvIGNyZWF0ZSBDRFJzL2JpbGxpbmcuDQoNCkluIGEgY2xvc2UgZW52aXJvbm1lbnQsIEkgY2FuIHVzZSB3aGF0ZXZlciBtZXRob2QgdG8gIHJlY29nbml6ZSBhIA0KZm9yd2FyZCBzaXR1YXRpb24uIEJ1dCBTSVAgaXMgYWJvdXQgaW50ZXIgb3BlcmFiaWxpdHkgYW5kIGludGVncmF0aW9uIA0KYW5kIEFGQUlLIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyBidXQgbm90aGluZyBzcGVjaWZpYyB0byBpbmZvcm0gb2YgYSBjYWxsIA0KZm9yd2FyZCBzaXR1YXRpb24sIEkgZG9uJ3Qga25vdyB0aGUgc3RhdHVzIG9mIERpdmVyc2lvbiBoZWFkZXIsIGJ1dCB0aGlzIA0KY2FuIGJlIGEgc29sdXRpb24gaWYgc3RhbmRhcmRpemVkLg0KDQpUaGFua3MNCg0KSm9uYXRoYW4gUm9zZW5iZXJnIHdyb3RlOg0KPiBUbyBiZSBjbGVhciwgQmFydWNoIGlzIHByb3Bvc2luZyBhIG5ldyBTSVAgaGVhZGVyLCB3aGljaCB0aGUgU0lQIFdHIA0KPiB3b3VsZCBuZWVkIHRvIHdvcnJ5IGFib3V0Lg0KPiANCj4gSSBkbyBub3QgdGhpbmsgc3VjaCBhIHRoaW5nIGlzIG5lZWRlZC4gQXMgS2VpdGggcG9pbnRlZCBvdXQsIG91ciANCj4gcGhpbG9zb3BoeSB0byBkYXRlIChhbmQgdGhpcyBpcyBhIGJyb2FkZXIgSUVURiB0aGluZyB0b28pLCBpcyB0byBtYWtlIA0KPiBzdXJlIHRoYXQgeW91IGNhbiAqYWNjb3VudCogZm9yIHdoYXQgaGFzIGhhcHBlbmVkLiBUaGF0IGlzLCB0aGF0IHRoZSANCj4gcHJvdG9jb2xzIGNvbnRhaW4gc3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byByZWNvcmQgd2hhdCB0cmFuc3BpcmVkIGluIGEgDQo+IGNhbGwvdHJhbnNhY3Rpb24vZGlhbG9nIG9yIHdoYXRldmVyLiBUaGVuLCBpdHMgc29tZW9uZSBlbHNlcyBwcm9ibGVtIA0KPiAoZm9yIGV4YW1wbGUsIDNncHApIHRvIHNwZWNpZnkgaG93IHRoZSBhcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiBpcyANCj4gY29sbGVjdGVkLCB3aGF0IGJpbGxpbmcgbW9kZWwgaXMgdXNlZCwgYW5kIGhvdyBhIENEUiBpcyBnZW5lcmF0ZWQuIE5vdCANCj4gdG8gc2F5IHRoYXQgdGhlc2UgdGhpbmdzIGFyZW50IGltcG9ydGFudCwgdGhleSdyZSBqdXN0IG5vdCB0aGUgU0lQIA0KPiB3b3JraW5nIGdyb3VwJ3MgcHJvYmxlbS4NCj4gDQo+IC1Kb25hdGhhbiBSLg0KPiANCg==_______________________________________________Sip mailing list  https://www1.ietf.org/mailman/listinfo/sipThis list is for NEW development of the core SIP ProtocolUse [email-masked] for questions on current sipUse [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 May 2004 08:06:03 -0700

The topic of what mechanism you use to know about this forwarding
information has been a long topic with much discussion. Right now, the WG
has selected the history mechanism (which grew out of the diversion work)
work as a WG item. The RPID work has become RFC 3325. Given the long history
of this, I highly recommend that if you think there is a reason that history
will not meet your needs, get that out very soon so that the history work
can be modified. 

I would be amazingly surprised to see diversion standardized.

Cullen

On 5/21/04 4:06 AM, "Dolly, Martin C, ALABS" <[email-masked]> wrote:

> A mechanism for relaying call forwarding information is needed, and I agree
> that the diversion draft is a viable solution.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Diego B
> Sent: Friday, May 21, 2004 4:29 AM
> To: Jonathan Rosenberg
> Cc: Roy, Radhika R, ALABS; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ?
> 
> 
> Hi;
> 
> Agreed, but my first question was exactly that, if there is a standard
> way or standard Headers, to store information about a "forward" call.
> 
> In a normal situation, no one will touch the From header and "normally"
> PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B
> number", and this is normally used to create the CDR.
> 
> I'm not trying to solve the CDR creation issue or how to bill a forward
> call, but I'm looking to a standard way to store forward information so
> one day this information will be used correctly to create CDRs/billing.
> 
> In a close environment, I can use whatever method to  recognize a
> forward situation. But SIP is about inter operability and integration
> and AFAIK there are some drafts but nothing specific to inform of a call
> forward situation, I don't know the status of Diversion header, but this
> can be a solution if standardized.
> 
> Thanks
> 
> Jonathan Rosenberg wrote:
>> To be clear, Baruch is proposing a new SIP header, which the SIP WG
>> would need to worry about.
>> 
>> I do not think such a thing is needed. As Keith pointed out, our
>> philosophy to date (and this is a broader IETF thing too), is to make
>> sure that you can *account* for what has happened. That is, that the
>> protocols contain sufficient information to record what transpired in a
>> call/transaction/dialog or whatever. Then, its someone elses problem
>> (for example, 3gpp) to specify how the appropriate information is
>> collected, what billing model is used, and how a CDR is generated. Not
>> to say that these things arent important, they're just not the SIP
>> working group's problem.
>> 
>> -Jonathan R.
>> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 24 May 2004 18:51:04 +0900

Hi,

History-Info is the way to go in IETF. I agree with it.
However, one of the missing pieces in History-Info, I think, is the 
mappings of redirection information from/to ISUP/ISDN network.
In diversion draft, draft-levy-sip-diversion-07, section 10, 
elaborated on this topics with the examples.

Does anyone have a clear idea about ISUP/ISDN and History-Info mapping?
Does anyone have a plan to elaborate how interworking can be achieved?
draft-elwell-sipping-redirection-reason may provide redirect reason
mappings. But it may also need redirection counter or address presentation
mappings when we require a certain level of transparency on call forwarding
services.

This interworking topic may be out of scope of IETF SIP WG and should be 
handled in other standard bodies like ITU-T or 3GPP.
But I want to be sure that History-Info can offer the capabilities which
can cover the mappings from/to ISUP/ISDN call forwarding services.

* For example, can we all agree with that redirection counter corresponds
  with the depth of the dotted index in the last History-Info header?
  We may allow pruning of the tree because in ISUP only the first and the last 
  redirection infomation can be conveyed.
  and so on...

Regards,
Takuya

P.S.
draft-levy-sip-diversion-07.txt has been deleted even before the expiration date.
Does anyone know why?
(07-version was published in January 2004, which means it will expire in July)

> >> to say that these things arent important, they're just not the SIP

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]