Subject: [martini] Review of GIN and outbound interaction

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 May 2010 19:18:27 -0600

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

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: AUDET François <[email-masked]>
Date: Tue, 18 May 2010 20:36:24 -0700

For all it's worth, the only case I've ever considered for this is what you call the B2BUA-type PBX case (i.e. one instance-id). And yes, indeed, the whole concept of caller prefs wouldn't apply to a sip trunk. This should just work. I haven't really considered at all the PBX-as-a-proxy case, because it doesn't really make sense to me (I would think domain-to-domain arrangement would apply in this context).

I believe your analysis is right. I think for GIN, I would say it applies only to the B2BUA case of PBX.

But I don't think it will be very obvious to the reader where outbound stops and where GIN begins. But then again, it wasn't so obvious with GRUU and outbound...

On May 18, 2010, at 18:18 , Cullen Jennings wrote:

> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 12:46:01 -0400

> 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 registr…

Anything that uses callerprefs based on sip.instance in an attempt to 
select a particular phone will be problematic.

It *could* still work, using a preference for the sip.instance value the 
actual UA registered with the pbx. But how the caller would ever learn 
about that is a little hard to see. I guess the reg event package, if 
handled by the pbx, would provide it. But picking it out of the remote 
contact from a prior call won't work as things are currently defined. 
But whether the call would even make it to the pbx will depend on how 
the preference criteria are framed. Done wrong and the call will be 
rejected at the SSP.

Callerprefs by instance id has always been problematic. GRUUs are a 
better solution to that.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 May 2010 17:46:28 -0600

> Callerprefs by instance id has always been problematic. GRUUs are a

Right ... it all comes back to me. Thanks Paul - I think that is more or less the answer. The part I was worried about does not really matter as is fine as long as systems uses GRUUs instead of the instance-ids in caller prefs.

Cullen Jennings