Re: [martini] #11: Section 7.3: Outbound Analysis

["martini issue tracker" <[e-mail]>]

#11: Section 7.3: Outbound Analysis
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  adam@…          
     Type:  defect                     |      Status:  assigned        
 Priority:  major                      |   Milestone:  milestone1      
Component:  gin                        |     Version:  1.0             
 Severity:  Candidate WG Document      |    Keywords:                  
---------------------------------------+------------------------------------

Comment(by bernard_aboba@…):

 Review from Cullen Jennings:
 http://www.ietf.org/mail-archive/web/martini/current/msg01539.html

 I sat down read outbound, had some coffee to brace myself for GIN, then
 read GIN, then convinced myself it would all work, then had more coffee
 and convinced myself it did not work, then convinced myself GIN was nuts,
 had more coffee , connived myself outbound was nuts, then had a bunch more
 coffee and decided that in limited cases, GIN and outbound do work
 together. But the combination of GIN, outbound, and GRUU do leave me
 feeling very jittery about if this will all work together (no it's not the
 coffee).

 A PBX could be done two ways. In one architecture it would be a proxy and
 each phone behind it a UA that registers to the PBX. In another
 architecture, the PBX could be a B2BUA and could look like a single or
 multiple UA's on the PBX to SSP connection that GIN is concerned with.

 Let's consider the B2BUA type PBX first as this is probably the most
 common. If the PBX used the same instance-ID for all the calls on the PBX
 to SSP side, and that was also used in the GIN registration, as far as I
 can tell,  it would just work for most the cases current PBX are
 interested in. It seem like it might break stuff on the SSP side that used
 the +sip.instance in caller prefs as two different phones behind the PBX
 would have the same +sip.instance value even though they were different
 phones. In practice, I'm not sure that anything important would require
 devices outside the PBX to look at the +sip.instance for UA in the PBX.
 You should run this by Paul K and see if he can think of something this
 would break.

 If the PBX wants to use different instance ID for the contacts on the PBX
 to SSP side, then I don't see how GIN would work but B2BUA based PBX
 probably don't need to do this.

 Moving on to proxy based PBXs. I not exactly obvious how GIN and and
 outbound would work for a proxy based PBX. Probably the best approach
 would be to have the proxy have  an "pseudo UA" that can deal with all the
 phone numbers and does the single GIN registration from PBX to SSP. Then
 when a call gets routed from the SSP to a given number at the pseudo UA,
 the pseudo UA in the PBX forwards the message to the appropriate UA that
 registered to the PBX. The UA would only register with the PBX and a
 single pseudo UA on the PBX would register (using GIN and outbound) with
 the SSP.

 So all in all, I think for some PBXes, GIN + outbound might work with
 almost no extra code and for other PBXes it might be a bit more work to
 get them both working - I can't imagine any solution that is significantly
 better or less work for the PBX to get both GIN and outbound.

 It's worth nothing that someone with the credentials to do a GIN
 registration has the credentials to hijack all the call for that PBX -
 typically outbound tries to stop one users form getting another users
 call. However both the designs above only require the PBX, not the phones
 attached to the PBX, to have that credential so I don't see that as a
 problem. It should be discussed in the security section.

 Cullen

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/11#comment:2>
martini <http://tools.ietf.org/martini/>