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

[Elwell, John]

Jamie,


________________________________

	From: Jamie Palmer [mailto:jamie at broadsoft.com] 
	Sent: 23 September 2008 18:22
	To: Johnston, Alan B (Alan); techwg at sipforum.org; Elwell, John
	Subject: [SIPForum-techwg] On the topic of REFER/Redirects...
	
	

	I've seen a few comments regarding the section on "services
related to retargeting" (section 17.5 in the original draft-00).  I was
surprised there weren't more.  This is on area where BroadSoft, as an
equipment provider on the service provider side, has seen a lot of
issues in the field.  This is why I wanted to make sure we captured some
guidelines.  Ahead of the meeting this week, I would like to make sure
we get a little more discussion, and agree to put this on the agenda for
Thursday / Friday.  

	 

	Spencer/Richard - I think this topic needs to be discussed at
the meeting.  I haven't seen an agenda (is there one?) - but would ask
that we include this on it.

	 

	The comments I've seen are from Alan and from John respectively
- and are well taken.  I have some comments inline below.

	 

	> > Section 17.5.2, page 39:

	> >

	> >

	> >

	> > I have a lot of problems with this section on REFER usage.

	> > The recommendation goes against

	> > draft-ietf-sipping-cc-transfer-09 (which is currently in AD

	> > evaluation, and will hopefully progress to RFC later this

	> > year).    The BYE is shown going in the reverse direction

	> > than usual (not that this is invalid or wrong, but it is

	> > unusual).  Also, it says the REFER MUST be sent in dialog,

	> > where cc-transfer recommends a separate dialog if GRUU and

	> > Target-Dialog are supported.  There is also no discussion

	> > about billing implications.  For example, if I am in a call

	> > with you through a service provider and send a REFER to my

	> > favorite 900 number psychic hotline, who gets billed?

	> >

	> >

	> >

	> > Section 17.5.3, page 41:

	> >

	> >

	> >

	> > This seems to suggest that a History-Info header field

	> > inserted by an enterprise would be used to generate billing

	> > records by the service provider?  Seems like there are some

	> > security implications we need to consider...  Also, is the

	> > purpose of this to allow a service provider to offer

	> > voicemail services to the enterprise?  Or is it mapping to

	> > ISDN?  If so, we should explicitly state this and make sure

	> > we have enough details to make this fully interoperable.

	> [JRE] I too have doubts in this area. I am doubtful about
mandating

	> support for History-Info. Charging should only be on the basis
of

	> authenticated information, e.g., digest or TLS mutual
authentication

	> would tell the service provider where the call comes from (on
the most

	> recent hop) and allow the enterprise to be charged.
Information in the

	> SIP message should be consistent with normal SIP principles,
i.e., From

	> and PAI represent the original caller, To represents the
original

	> callee, History-Info (if present) can provide additional
information.

	> 

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

	 

	John

	 

	Regarding section 17.5.2, the use case that I'm trying to
address here is e).  I'm suggesting that the REFER be in-dialog, so as
to avoid any requirements for GRUU and Target-Dialog.  In other words -
I think this is the simplest thing to mandate that gives us support for
this service flow.  Regarding billing - the service provider network has
everything it needs in the REFER to determine which party should be
billed - and it can (and probably should) challenge the REFER to make
sure that it is authorized to perform the action on that dialog.   This
section should be expanded to clearly spell out that the REFER should be
treated the same way as all other transactions originated from the
enterprise.   Regarding who sends the BYE transaction - I'm not too hung
up on this.  Either would work...and would have no effect on the
functionality or the billing.  I guess we could leave the BYE
transaction out.   

	 

	Regarding section 17.5.3, the use cases here are c) and d).  For
all intents and purposes, this looks like any other new-dialog INVITE
originating from the enterprise to the service provider network.  So it
should follow all the same rules that we spell out for new INVITEs and
how they are authenticated, what's in the From, what's in the To, etc -
and I tried to avoid those details - but perhaps ended up confusing the
matter.  The reason for the History-Info is that it gives the necessary
detail to deposit the call to the right mail box for use case c).
Although, it can provide extra "billing detail" - I agree that the real
charged party for the call is based off the authentication of the INVITE
itself - not the HIistory-Info.  

	 

	Regards,
	JBP

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