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

["Francois Audet" <[e-mail]>]

> > 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-rea
> > so
> > n=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.

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.

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?

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

(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.

_______________________________________________
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