[SIPForum-techwg] Call Transfer initiated from SP network

Francois Audet audet at nortel.com
Mon Feb 23 11:53:49 EST 2009


In many markets, the rates are so low (or flat) that it makes no difference
whatsoever.

I think it really would be innapropriate to bastardize the protocol because
of perceived issues on pricing. 

I'm ok with the spec saying that's it possible to turn off the feature. Sure. 

I would also say that's it's possible for a service provider to correlate
the INVITE resulting from the REFER to the actual call if it has/choose to
use "traditional" pricing. It's not rocket science.

Finally, I have seen a very large service provider insisting that the
manufacturer MUST support REFER because they want to use it for
Contact Centers.

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell at siemens.com] 
> Sent: Sunday, February 22, 2009 23:20
> To: Cullen Jennings; Spencer Dawkins
> Cc: Johnston, Alan B (Alan); Audet, Francois (SC100:3055); 
> techwg at sipforum.org
> Subject: RE: [SIPForum-techwg] Call Transfer initiated from SP network
> 
> Cullen,
> 
> We had this discussion a few weeks ago, and I was expressing 
> similar points to what you are making (but unfortunately not 
> getting sufficient support). The result was that the SIP-PBX 
> MUST support receipt of REFER, but it is up to enterprise 
> policy whether such a REFER can be accepted.
> My opinion was that enterprises would not be able to accept, 
> unless satisfied with the arrangements the SP makes for 
> charging the resulting calls. And as you say, this is not an 
> easy thing for SPs to implement, so many will be unable to do 
> so satisfactorily.
> 
> John
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy at cisco.com]
> > Sent: 22 February 2009 17:51
> > To: Spencer Dawkins
> > Cc: Elwell, John; Johnston, Alan B (Alan); Francois Audet; 
> > techwg at sipforum.org
> > Subject: Re: [SIPForum-techwg] Call Transfer initiated from 
> SP network
> > 
> > 
> > How do the SP folks feel about adding the text
> > 
> > If the A sends a refer to B to call C. The SP MUST NOT bill 
> B for the 
> > call to C but MAY bill A.
> > 
> > That's what you are asking for here. Few SP are going to be able to 
> > implement thins and toll fraud options around it are huge. The 
> > basically problem is that it requires the SP to do some multi party 
> > complex billing authorization. They have to remember A sent 
> a refer to 
> > B and what was in it and then use that as a token to authorize the 
> > call for B to C which is good from some period of time but not too 
> > long. For people doing prepaid call this is a nightmare.
> > 
> > more inline ...
> > 
> > On Jan 22, 2009, at 9:59 AM, Spencer Dawkins wrote:
> > 
> > > OK...
> > >
> > > Could people comment on this (new) text, letting the rest of the 
> > > working group know if it is acceptable?
> > >
> > > Thanks,
> > >
> > > Spencer
> > >
> > > 12         Call Transfer Services
> > >
> > >
> > > The ability for the SIP-PBX to transfer calls through the 
> SIPConnect 
> > > interface is considered a basic requirement in this specification.
> > > This
> > > section specifies a set of SIP primitives that can be used to 
> > > support call transfer services in a SIPConnect network.
> > 
> > 
> > >
> > >
> > > Call transfer can be accomplished by the use of REFER requests (a 
> > > "proxy model"), or by the use of one or more INVITE requests (a 
> > > "third- party call control model"). Both are supported in 
> > > SIPConnect.
> > >
> > > Service providers using the proxy model with REFER are
> > cautioned to
> > > examine
> > > carefully possible interactions with charging considerations.
> > 
> > It's not the SP that have the problem it is the PBX. The 
> model of many 
> > of the SP is when enterprise B sends and INVITE to C, they 
> get billed 
> > for that. So this means PBX need to be able to reject all 
> REFERs. So 
> > if some PBX are doing that and some are sending them, we still need 
> > things to interop and the text here is not going to result 
> in transfer 
> > that works from user point of view.
> > 
> > >
> > >
> > >
> > >
> > >> In the interests of progress, let's go along with
> > Francois' approach,
> > >> but make sure we include some discussion of the need to 
> ensure the 
> > >> capability cannot be abused.
> > >>
> > >> John
> > >>
> > >>> -----Original Message-----
> > >>> From: techwg-bounces at sipforum.org
> > >>> [mailto:techwg-bounces at sipforum.org] On Behalf Of 
> Johnston, Alan B 
> > >>> (Alan)
> > >>> Sent: 21 January 2009 21:49
> > >>> To: Francois Audet; techwg at sipforum.org
> > >>> Subject: Re: [SIPForum-techwg] Call Transfer initiated from SP 
> > >>> network
> > >>>
> > >>> I support this approach.  If we can get all IP-PBX to
> > support REFER
> > >>> transfers, and some SPs to support it, we will have 
> progressed the 
> > >>> industry a long way in the right direction.
> > >>>
> > >>> Thanks,
> > >>> Alan
> > >>>
> > >>> -----Original Message-----
> > >>> From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org
> > >>> ]
> > >>> On Behalf Of Francois Audet
> > >>> Sent: Tuesday, January 20, 2009 3:13 PM
> > >>> To: Elwell, John; Spencer Dawkins; Jamie Palmer; David Hancock; 
> > >>> techwg at sipforum.org; DOLLY, MARTIN C, ATTLABS
> > >>> Subject: Re: [SIPForum-techwg] Call Transfer initiated from SP 
> > >>> network
> > >>>
> > >>> Here is what I think:
> > >>>
> > >>> - I think we would do the industry a big service to have MUST 
> > >>> support receiving mid-call REFER  for the IP-PBX. It 
> will be a lot 
> > >>> better for the service providers who prefer to use  it 
> to simplify 
> > >>> their architecture.
> > >>>
> > >>> - But... We should probably add some discussion about the fact 
> > >>> that we can not EXPECT that this  is how transfer or other 
> > >>> features will necessarily be done. We would explain that for  
> > >>> various reasons, re-INVITEs/UPDATEs in a third party 
> call control 
> > >>> model is often used.
> > >>>
> > >>> That way, the service provider has the option to use 
> whatever is 
> > >>> best for their environment.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Elwell, John [mailto:john.elwell at siemens.com]
> > >>>> Sent: Tuesday, January 20, 2009 12:06
> > >>>> To: Audet, Francois (SC100:3055); Spencer Dawkins; 
> Jamie Palmer; 
> > >>>> David Hancock; techwg at sipforum.org; DOLLY, MARTIN C, ATTLABS
> > >>>> Subject: RE: [SIPForum-techwg] Call Transfer initiated from
> > >>> SP network
> > >>>>
> > >>>> Francois,
> > >>>>
> > >>>> Maybe it is just my fear, but I would welcome opinions from 
> > >>>> others in order to help reach a conclusion on this issue.
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> techwg mailing list
> > >>> Send mail to: techwg at sipforum.org
> > >>> Unsubscribe or edit options at:
> > >>> http://sipforum.org/mailman/listinfo/techwg
> > >>>
> > >>> _______________________________________________
> > >>> techwg mailing list
> > >>> Send mail to: techwg at sipforum.org
> > >>> Unsubscribe or edit options at:
> > >>> http://sipforum.org/mailman/listinfo/techwg
> > >>>
> > >>
> > >> _______________________________________________
> > >> techwg mailing list
> > >> Send mail to: techwg at sipforum.org
> > >> Unsubscribe or edit options at:
> > >> http://sipforum.org/mailman/listinfo/techwg
> > >>
> > >
> > >
> > > _______________________________________________
> > > techwg mailing list
> > > Send mail to: techwg at sipforum.org
> > > Unsubscribe or edit options at:  
> > http://sipforum.org/mailman/listinfo/techwg
> > 
> > 
> 



More information about the techwg mailing list