Subject: [Sipping-tispan] RE: Voicemail-uri draft

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 16 Nov 2005 13:36:58 +0100

Hi,

Further comments:

1/ How to convey the original called identity
---------------------------------------------
I was told that the "To" header was meant to convey the original called identity while the target was to convey the redirecting identity. 

This prevents the Call Forwarding service to change the "To" header (and set it to the logical "forwarded-To" identity). In this respect the service-retargetting draft is better than the voicemail-uri draft.

Additionnaly, some signaling system such as H.323 (without H.450 series) are only capable of providing the redirecting identity. In this case there is no Original Called identity and the mapping to and from SIP will be impossible.

2/ Redirecting counter
----------------------
In certain situations, operators may wish to limit the number of call forwardings (e.g. they don't want to risk loops A->B->A). There is a need to be able to count the number of call forwarding events (see levy-draft for example).  

sebastien

-----Message d'origine-----
De : Francois Audet [mailto:[email-masked]] 
Envoyé : mardi 15 novembre 2005 01:24
À : Cullen Jennings; GARCIN Sebastien RD-CORE-ISS
Cc : [email-masked]; Roland Jesske; Denis Alexeitsev; CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; Hans Erik van Elburg (RY/ETM); [email-masked]; John Elwell
Objet : RE: Voicemail-uri draft

> > From a technical point of view this draft is currently does
> not meet
> > Call Diversion requirements (and not only because of PSTN 
> > interoperability).
> > 
> OK, you will need to help me understand what is needed and I do plan 
> to make some small changes to the draft.

>From a technical point of view, voicemail-uri is identical to service-retargeting. 

In fact, retargeting reason was a re-write of voicemail-uri.

> > 1/ The draft does not address redirecting number which is mandatory 
> > requirement for TISPAN (if IETF won't consider billing,
> TISPAN will be
> > forced to define a P-header for this purpose)
> IETF would probably call it accounting not billing but I don't think 
> IETF has any fundamental objections to billing.
> Can you help explain the requirements here?

Cullen, I think section 8 is a little confusing with regards to retargeting and probably needs some changes.

The target is intended to be mapped to the redirecting number, and we should probably be silent on billing. I assume other groups (like TISPAN) can discuss it if they want in their own spec.

It does not need another header.

> > 
> > 2/ The draft assumes the SIP responses code are fit for
> providing Call
> > Diversion reason. We believe that this is not true and
> seems more like
> > a trick than a proper standard solution. I would recommend to use 
> > explicite reason values based on ITU-T Q.733 as done in a number of 
> > other drafts.
> 
> Can you provide specific reasons why the SIP codes, or extensions to 
> them will not work. Many people at the IETF meetings provided many 
> reason why a separate code space would not interoperate very well with 
> sip systems.

Agreed: some justification would be useful.

> > 
> > 3/ The draft assumes that there is "no call leg between B
> and C". If
> > this is the case, then this draft is not fit for Call Diversion 
> > simulation service because this is how Call Diversion works whether 
> > IETF like it or not.
> I'm a bit lost here. If there is a call leg like you describe then it 
> seems there would also be an B2BUA? seems it would be easy in this 
> case but I imagine I am confused.
> 
> > 
> > 4/ Privacy of the forwarding leg is not addressed.
> OK - What is needed to be kept private and from whom?

My take is that Privacy should be in a privacy document, applicable not just to voicemail, but to everything. 

> > 
> > 5/ The scope of the draft should be made broader the
> "voicemail", the
> > voicemail application is one example application that
> benefits from a
> > Cal Diversion service
> 
> I agree. Can you tell me about the other services it is used for? I've 
> tried to make it clear the draft was applicable to many PSTN interop 
> situations.

IVR systems, contact centers, etc.

> > 
> > Will the new version of the voicemail-draft will address all these 
> > issues in time for our needs ?
> 
> 
> IETF is very consensus oriented and it is frustrating at times. There 
> has been several years of work to get this draft where it is - if it 
> can be tweaked a little and meet most of your needs, the questions you 
> need to ask yourself is there something else that is better than can 
> be done sooner? If you think that an alternative draft can reach 
> consensus much sooner, I have no reasons to try and push this one. I'm 
> just trying to help on it.

Let us look at the draft and make sure it addresses your requirements.

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2005 10:50:43 -0500

sebastien,

> 1/ How to convey the original called identity

The To contains the *original* (first) target.
The R-URI contains the *current* (last) target.
The H-I header can contain intermediate targets.

If the request has to go through a gateway to get to the last target, 
then it is possible to put the gateway address in a Route header to 
avoid messing up the target address.

Given that a request can be retargetted multiple times, I don't know how 
much better we can do than that. What is missing?

> Additionnaly, some signaling system such as H.323 (without H.450 series) are only capable of providing the redirecting identity. In this case there is no Original Called identity and the mapping to…

Oh. So now it is H.323 that is deficient, not SIP! :-)

So if a call is coming from H.323 into sip the gateway will have to pick 
the oldest target available and call it the original target. Any 
limitations in the resulting call will have to be blamed on H.323 
inadequacies.

	Paul