[SIPForum-techwg] Thoughts on registration in SIPconnect

[Rastogi, Vipul (Vipul)]

 When PBX Registers with SP with option 2, SP thinks whole PBX as a
single UA (just like any other endpoint). I am not sure if it is proper
to say SP thinks PBX as proxy (and hence doing DNS etc).
It is fare assumption that there are multiple such PBX in single
enterprise working with single of multiple SP. In that case
sip:*@enterprise.com might not work.

Vipul Rastogi

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Elwell, John
Sent: Tuesday, October 14, 2008 9:30 PM
To: techwg at sipforum.org
Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect

I have had some off-line discussions with some IETF experts, and I have
detected some concern about the direction that SIPconnect is heading
with its use of registration. There was already concern during the
Denver meeting about the complexities of the registration-based
approach.

I could try to summarise the registration-based approach as follows:

With registration, a PBX to registers a default AoR such as:
	sip:+123456000 at enterprise.com;user=phone
and as a result can receive all inbound requests to that enterprise.

In principle, this should mean all requests targeted at
sip:*@enterprise.com, e.g.:
	sip:alice at enterprise.com
	sip:12345 at enterprise.com
	sip:+123456789 at enterprise.com;user=phone
should be delivered to the PBX.

In these cases, the domain part is enterprise.com, so the SP shouldn't
look at the user part.

However, in practice, the SP is also going to receive requests targeted
at, for example:
	tel:+123456789
	sip:+123456789 at serviceprovider.net;user=phone

In these cases, the E.164 number is "assigned" to enterprise.com, the SP
needs to recognise this and forward the request to the PBX, but with,
enterprise.com in the domain part (otherwise the PBX will reject the
request, or try to forward it back to the SP). So it would end up being
forwarded as:
	sip:+123456789 at enterprise.com;user=phone

The fact that the PBX has registered really makes no difference to the
SP's decision to forward a request to the PBX:
- whether or not the PBX has registered, requests targeted at
*@enterprise.com need to be delivered to the PBX;
- whether or not the PBX has registered, requests targeted at an E.164
number assigned to the PBX need to be retargeted to a SIP URI with
enterprise.com in the domain part, and then delivered to the PBX as
above.

The only difference that registration makes is that it provides a "flow"
over which requests can be delivered (rather than using RFC 3263 to
determine where to route to) and that "flow" is kept alive.

It seems that a similar result could be obtained by using connection
re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the
PBX could establish a connection to the SP using OPTIONS and keep it
alive using OPTIONS, and the SP could re-use this connection for inbound
requests to the PBX. This would avoid the use of REGISTER, and would be
closer to SIPconnect 1.0 (where the PBX was not required to register).

By doing something like this, we could converge on a single mode of
operation and keep the basic implementation requirements to a minimum.

If something along these lines does not satisfy requirements, let's get
the requirements on the table so that we can see which items in the SIP
tool kit would do the job.

John

_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg