[SIPForum-techwg] On the topic of REFER/Redirects...

[Jamie Palmer]

John,

 

 

[jbp]  So, my intent in writing this section was to make sure we had
some recommendations around the redirecting use cases.  There are a lot
of known issues with SIPConnect 1.0 that we have seen in the field -
specifically the following scenarios do not always work because it is
unclear what is required from the enterprise network and the service
provider network:

a.       Forward incoming PSTN caller back to PSTN number.

b.       Forward incoming PSTN caller back to hosted voicemail

c.       Forward incoming internal caller out to hosted voicemail

d.       Forward incoming internal caller out to PSTN number.

e.       Blind transfer incoming PSTN caller back to a PSTN number

f.         Attended transfer incoming PSTN caller back to a PSTN number

g.       Blind transfer incoming internal caller out to a PSTN number

h.       Attended transfer incoming internal caller out to a PSTN number

 

The main issues we are seeing with all of these use cases are related to
signaling and billing.  Because they are all very very common service
flows --- we need to make sure we have interoperability clearly spelled
out. 

 

Section 17.5.1 addresses a) and b) - and IMO are the cleanest way to
support those use cases.  
[JRE] In general this would work, but there may be some cases where it
doesn't. One case may be where the call arrives from one SP (or maybe
from some other enterprise using direct enterprise-enterprise peering)
but for some reason needs to be forwarded to a different SP. Another
case is where the identity of the forwarded-to user is not to be
revealed to the caller.

 

[jbp]  I'm just covering the classic service scenarios - 80x20 rule.
Surprisingly - we have found many cases where even these service flows
aren't well supported.   For the more complex case you describe, where
the call arrives via SP A and is delivered from enterprise 1 to
enterprise 2 via peering - if that call is forwarded out to SP B  - then
I would suggest, from the perspective of SP B, this looks like use case
c) or d) and is covered in the section 17.5.3.  

 

The privacy requirement you point out is valid - but it isn't easily
solved unless the IP-PBX stays in the call flow - or alternatively, it
puts trust in the SP to honor its privacy policies.  I would think the
latter is the norm.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20080923/0f2645bb/attachment.html