Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!)

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 6 Mar 2010 13:47:55 -0800

Dean said:

"So, other than a dynamic routing protocol that meets inter/intra-ITAD
routing requirements and could be derived from TRIP (or built using some
other model, such as a SIP event package), what are we missing?"

[BA] I think there is quite a bit missing, actually.  In practice, a video
call may need to be routed differently from a pure voice call, even in the
case of an INVITE with a Request-URI that represents a phone number.  For
example, a PBX might typically be set up to route calls to a SIP trunk based
on the phone number in the Request-URI.  However, if the SSP is not be
capable of supporting video, a number of undesirable things might happen:
the call might succeed but only bring up audio due to "SDP scrubbing" by the
SSP, or call setup might fail entirely.  There are multiple ways to handle
the problem today.  One way is to dual-register the endpoints, with one of
the registrations being to a special "video network" that might assign real
(or bogus) "phone numbers" to the endpoints, allowing them to call each
other as if they were all attached to a single pseudo-PBX.  Another way is
to first try to route the call via mechanisms that try to find routes less
likely to lose functionality (e.g. an "ENUM trunk", a "DUNDI trunk" or a
"VIPR trunk").  However, those mechanisms are somewhat under-developed
today.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 06 Mar 2010 17:53:17 -0500

Am I the only one that finds it absurd that one would have to route the 
signaling differently based on the media in the call?

Among other things, this means that INVITEs without offers may well not 
get the desired result, and mid-call addition of media may not work.

	Thanks,
	Paul

Bernard Aboba wrote:
> Dean said:
> 
> “So, other than a dynamic routing protocol that meets inter/intra-ITAD 
> other model, such as a SIP event package), what are we missing?”
> 
>  
> 
> [BA] I think there is quite a bit missing, actually.  In practice, a 
> video call may need to be routed differently from a pure voice call, 
> /even in the case of an INVITE with a Request-URI that represents a 
> phone number./  For example, a PBX might typically be set up to route 
> calls to a SIP trunk based on the phone number in the Request-URI. 
>  However, if the SSP is not be capable of supporting video, a number of 
> undesirable things might happen:  the call might succeed but only bring 
> up audio due to “SDP scrubbing” by the SSP, or call setup might fail 
> entirely.  There are multiple ways to handle the problem today.  One way 
> is to dual-register the endpoints, with one of the registrations being 
> to a special “video network” that might assign real (or bogus) “phone 
> numbers” to the endpoints, allowing them to call each other as if they 
> were all attached to a single pseudo-PBX.  Another way is to first try 
> to route the call via mechanisms that try to find routes less likely to 
> lose functionality (e.g. an “ENUM trunk”, a “DUNDI trunk” or a “VIPR 
> trunk”).  However, those mechanisms are somewhat under-developed today.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 6 Mar 2010 15:41:13 -0800

I don't think you are alone here.  The current state of things is barely
workable for intra-domain operation, let alone inter-domain.  Many of the
hacks required either have lots of failure modes or have such limited
applicability or scaling characteristics they are barely worth the effort 
to configure them. 

Given the current state of things, I have seen situations where customers
have chosen public services like Skype, Live Messenger or GoogleTalk
over SIP.   

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Saturday, March 06, 2010 2:53 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!)

	Thanks,
	Paul

Bernard Aboba wrote:
> up audio due to "SDP scrubbing" by the SSP, or call setup might fail 
> to a special "video network" that might assign real (or bogus) "phone 
> numbers" to the endpoints, allowing them to call each other as if they 
> lose functionality (e.g. an "ENUM trunk", a "DUNDI trunk" or a "VIPR 
> trunk").  However, those mechanisms are somewhat under-developed today.
> 
>

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 7 Mar 2010 11:04:39 +0000

Hi Paul, folks,
 Nope. You are not. This discussion was raised a Loooooong time ago (in the London/SLC meetings, IIRC), so people have had your view for at least that long.

The consensus then was that even if one had separate identities for separate services with separate media features, these would be subsumed by a single registrar-proxy, and you would have one common "outward facing" identity. That proxy would fork any requests as needed. SIP would negotiate any service-specific routing, so there was no problem.
In call capability negotiation would handle the rest.

The issue I had with that at the time was that "joe punter" might get SIP service from a set of CSPs, each of which was severely limited in the media features it handled. Voice might be handled by one CSP whilst IM might come from another CSP. There would be no practical leverage for mortals to convince those providers to offer full service, or to convince (for example) AT&T systems to register with a front-end MCI proxy. SIP full service might not be provided, regardless of the logic in the IETF's argument.

In those cases where the end user has fully functional devices, and is supported by fully functional CSPs, it all works. (Re-)routing based on media features is not an issue.

In the real world... one has to ask oneself what's absurd?

all the best,
  Lawrence

On 6 Mar 2010, at 22:53, Paul Kyzivat wrote:

> Am I the only one that finds it absurd that one would have to route the signaling differently based on the media in the call?
> 
> Among other things, this means that INVITEs without offers may well not get the desired result, and mid-call addition of media may not work.
> 
> 	Thanks,
> 	Paul
> 
> Bernard Aboba wrote:
>> Dean said:
>> “So, other than a dynamic routing protocol that meets inter/intra-ITAD routing requirements and could be derived from TRIP (or built using some other model, such as a SIP event package), what are we missing?”
>> [BA] I think there is quite a bit missing, actually.  In practice, a video call may need to be routed differently from a pure voice call, /even in the case of an INVITE with a Request-URI that represents a phone number./  For example, a PBX might typically be set up to route calls to a SIP trunk based on the phone number in the Request-URI.  However, if the SSP is not be capable of supporting video, a number of undesirable things might happen:  the call might succeed but only bring up audio due to “SDP scrubbing” by the SSP, or call setup might fail entirely.  There are multiple ways to handle the problem today.  One way is to dual-register the endpoints, with one of the registrations being to a special “video network” that might assign real (or bogus) “phone numbers” to the endpoints, allowing them to call each other as if they were all attached to a single pseudo-PBX.  Another way is to first try to route the call via mechanisms that try to find routes less likely to lose functionality (e.g. an “ENUM trunk”, a “DUNDI trunk” or a “VIPR trunk”).  However, those mechanisms are somewhat under-developed today.

---

From: Dean Willis <[email-masked]>
Date: Sun, 7 Mar 2010 12:37:55 -0600

On Mar 6, 2010, at 3:47 PM, Bernard Aboba wrote:

> Dean said:
> “So, other than a dynamic routing protocol that meets inter/intra- 
> ITAD routing requirements and could be derived from TRIP (or built  
> using some other model, such as a SIP event package), what are we  
> missing?”
>
> even in the case of an INVITE with a Request-URI that represents a  
> phone number.  For example, a PBX might typically be set up to route  
> However, if the SSP is not be capable of supporting video, a number  
> of undesirable things might happen:  the call might succeed but only  
> bring up audio due to “SDP scrubbing” by the SSP, or call setup  
> might fail entirely.  There are multiple ways to handle the problem  
> today.  One way is to dual-register the endpoints, with one of the  
> registrations being to a special “video network” that might assign  
> real (or bogus) “phone numbers” to the endpoints, allowing them to  
> call each other as if they were all attached to a single pseudo- 
> PBX.  Another way is to first try to route the call via mechanisms  
> that try to find routes less likely to lose functionality (e.g. an  
> “ENUM trunk”, a “DUNDI trunk” or a “VIPR trunk”).  However, those  
> mechanisms are somewhat under-developed today.

Most of that routing would seem to be done between the terminating- 
AOR's service proxy and the user agent. which is an entirely separate  
part of the routing problem that is currently handled by registration.  
I'll admit that I've also proposed a different sort of dynamic routing  
as an alternative to registration, but whatever that is, it doesn't  
feel like BGP, and might well have service-specific aspects (as does  
REGISTER, via RFC 3840/3841).

--
Dean