Subject: RE: User signaling -- was DTMF signaling between media gateways - ouch!

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 24 Nov 1999 15:58:17 -0600

Dean Willis [mailto:[email-masked]] writes:
> I happen to believe that the open-ended nature of the SIP INFO approach I
> have discussed provides for some very powerful and easily implemented
> applications. 

I agree with that.

> SIP provides arbitrary application messaging support with INFO
> and MIME bodies. 

And I guess this, too.

> SIP provides automatic scoping to the nodes contained in
> the signaling path, with an opt-out mechanism for nodes that don't want to
> play, transparency for nodes that don't care, and negotiation mechanisms
> for nodes that think they might want to care. 

What I still don't quite get, though, is why this "arbitrary application
messaging support" is sent via the "signaling path", rather than more
directly to the application on the other end.  

If everything is being sent best-effort, and all the intermediate nodes opt
out, it's no big deal.  

But if there are nodes still in the signaling path because they *might* want
to care about the session (to provide some service based out of a SIP
network server), then they are going to see all the signaling traffic (in
the SIP info messages) an arbitrary end application might send their way --
even though they don't care about that end application at all.  This makes
it harder to engineer those platforms, and the network around them (there
could be reserved paths to those servers, for instance, to provide better
quality for SIP network-based services).  Might it not even be conceivable
that the INFO message could get forked or redirected at a network server
along the way?

My thought is that if the end system applications are signaling to each
other, they'd want to avoid the stuff in the middle as much as possible,
just like the media steams do.  Just as the SIP network servers wouldn't
want to be bothered with just forwarding data between applications (even
signaling data), it would seem the applications would want to subject their
signaling data to whatever might happen in the SIP network (possible
charging, QoS variations, node congestion, whatever).

Tim Schroeder

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Nov 1999 23:22:14 -0600

Tim writes:
> Dean Writes:

Well, you have an implementation decision about how to build
endpoint-endpoint communications. You could certainly build your own
protoco, use Java RMI, MS DCOM, or any number of other things. I expect
people will build systems that use all of the above. But if doing it at the
SIP level makes sense to the app developer, it is an easy option.

One of the reasons I find this approach to be interesting is the
intersection with that slayer of useful protocols, the "corporate firewall".
Many businesses require application-level proxies for all traffic. Given
that the corporate SIP proxy has to provide this function for SIP messages
like INVITE and BYE, it seems clear that it could be used for the occasional
end-to-end datagram as well.

I see the corporate SIP proxy as controlling the firewall to allow media
passage for the RTP streams. It can do this because it is 1) a trusted node,
2) in the signaling path, and 3) capable of authenticating the internal
endpoint.

Certainly one could design another end-to-end protocol, describe it in SDP,
add awareness of it to the firewall-controlling proxy, find a way to secure
it, and use it for your needs. But that seems like a faily heavy-handed
approach to just schlepping a MIME blob from one node to another.

--
Dean

Have you ever tried to get H.323 through a firewall? Great, now try again
with payload security . . .

--
Dean