Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

[Paul Kyzivat <[e-mail]>]

Francois,

[Tried to clean up the quoting so this is readable]

More inline.

	Paul

Francois Audet wrote:
> Paul Kyzivat wrote:
>> Francois Audet wrote:
>
>>>Personally, I think the best way to do this would be to 
>>>have the first retarget to point to:
>>
>>>sip:[e-mail];old-target=sip:[e-mail];
>>>   retargeting-reason=busy
>>
>>You are suggesting that proxy B do the retargetting for proxy 
>>C? These don't even have to belong to the same provider!
>>
>>At the time B is retargetting, all it knows is sip:[e-mail]. 
>>(Sorry, I wrote this with user b and c having the same 
>>domain. I should have used different domains for them.)
>>
>>>So it would avoid the "normal" routing steps afterwards, 
>>>and the whole 
>>>problem in the first place. I.e., don't use an AOR but a valid 
>>>resolved contact.
>>>
>>>That being said, if one is a masochist, you could decide to 
>>>parse the 
>>>History-Info including the information (which I wouldn't do 
>>>because it 
>>>is subject to be filtered out by "the network").
>>
>>Then how do you make my use case work? Or doesn't it?
> 
> I must be misunderstanding your use case.

Or I am misunderstanding a case in the draft.

> It doesn't seem to make sense to me that B would retarget to C (in a
> different
> domain), and that you would expect the target in C's domain to
> understand
> parameters that where added by B.

The case I am describing above is like the cases involving a "deputy". I 
would imagine a "deputy" would be referenced by an AOR.

The following is from the draft introduction:

    For example, a request could be retargeted to a destination that can
    handle requests that encounter busy or no reply at the original
    target. As another example, a user could arrange that requests
    targeted at the user be retargeted to a deputy, perhaps because the
    original user expects to be absent or does not wish to be disturbed.
    The fact that a request has been service retargeted is often of
    interest to the users involved, i.e., the retargeted-to user and the
    calling user, or to an application. Therefore it would be very useful
    to provide to the UAS and the UAC details of retargeting in the form
    of the original target URI, the retargeted-to URI and the reason for
    retargeting.

This clearly seems to include a case where the retargetted-to user is 
indeed a "user" and not an "application". Presumably the "application" 
includes the VM case. But if it is a "user", then in sip terms, what is 
it? I think it is probably an AOR. If so, and if the goal is to provide 
the retargetting details to the UAS, then how does this happen? It seems 
that it can only happen if the proxy representing the retargetted-to AOR 
copies the parameters into the contact address when forwarding on to the 
registered contact.

Also, if the retargetting reason, etc. parameters are only inserted into 
the URI when the target is known to be a server that will use them, then 
how does this involve PSTN gateways. It seems like you would only use 
this when forwarding to a phone number that is known to denote a 
voicemail server. How often is that done? I would think most of the 
cases of forwarding to the PSTN are like forwarding to a deputy.

> If my Nortel college calls me at Nortel, and I'm forwarded to you at
> Cisco, 
> and you are forwarded to Cisco's voicemail, surely you would expect my
> college
> to get YOUR mailbox, not mine, right?

Yes, I would *expect* that, though it is probably not what I would 
*desire*. What I would desire, at least in many cases, is that your 
colleague would call you, the call would be forwarded to me, and that if 
I failed to answer the call would not be forwarded to my voicemail. 
Instead, the proxy acting for me would give up, and then the proxy 
acting for you would forward the call to your mailbox.

> In other words, it seems that only the last redirection is useful in 
> this case.

It seems to me that only the redirection that goes to a mailbox matters, 
whether it be the first, last, or some other.

> (If you really want to parse the first redirection, you can look at the
> H-I,
> it's legal of course, but I'm wondering about how practical it is in
> real life...)
> 
> Again, maybe I'm misunderstanding what you are saying.

I do think there is some kind of miscommunication here, but can't quite 
figure out what it is.

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