Subject: General question on SIP used b/w MGCs

From: <[email-masked]>
Date: Fri, 7 Jan 2000 17:41:54 +0530 (IST)

Hi,
I recently went thru all the drafts related to PSTN interworking in
hgs' site.

Now the impression I might have incorrectly formed seems to be that
all SIP is doing is providing a wrapper for any payload (ISUP, etc) that
needs to be transmitted b/w MGCs.

I had a look at both the INFO and the MIME Types - my current
understanding is that if an MGC wants to transmit a signal to another MGC,
it just creates a SIP Message (INVITE, INFO etc) and just puts the
complete signal
to be transmitted in the boddy. 
Now the receiving MGC extracts the body and interprets the signal in what
ever way it was meant to be interpreted.

Now if SIP is only acting as a wrapper, why is it that people seem to
mention that SIP is the preferred interaction scheme b/w MGC - MGC ?

Could some one point me to papers (besides the pstn drafts I mentioned)
helping me out with this ?

Actually the statements abovr must be quite naive, as I dont know much
about the MGC side  :-)

Anyway, I would like to know if besides being just a wrapper which is only
tunelling signals to and fro, is there any other advantage of SIP b/w two
MGCs ?

Thx
Regds
Arjun
Arjun Roychowdhury @ Hughes Software Systems

On Thu, 6 Jan 2000, Jonathan Rosenberg wrote:

> 
> 
> 
> 
> The first problem is that there is no way I know of in RSVP for one
> reservation to preempt another, and for notification of preemption to be
> delivered (there has been some work on MPLS extensions to RSVP which
> allow replacement, but I don't know if thats useful for this
> application).
> 
> Even if it did, I'm not really sure it matters. This isn't a circuit
> network; pre-emption does not imply a one to one replacement of one
> circuit with another. One could add priorities to an rsvp reservation so
> it always succeeds; all this means is that the loss rate of existing
> connections is increased if there really wasn't enough bandwidth for the
> new one. You can rely on human response to that to hang up if it gets
> really bad. In most cases, I suspect a WAN connection that supports any
> kind of data traffic at all will have sufficient resources so that these
> high priority reservations won't impact one drop existing calls.
> Furthermore, adaptive mechanisms that use FEC or redundanct codecs will
> allow performance to be probably not bad for loss rates that are quite
> high.
> 
> -Jonathan R.
> 
> 
> 
> Bob Bell wrote:
> >
> > Jonathan -
> >
> > I understand that this is a different aspect of the problem. It does bear
> > on SIP in that if a lower priority call is "preempted", there is supposed
> > to be a signal given to the end stations indicating that they have been
> or
> > are being preempted. That signal would need to be SIP. How and where it
> is
> > originated is a totally different issue and one I don't currently know
> how
> > to solve. There would need to be some form of feedback from RSVP or
> > DIFFSERV or ???? to allow for that interaction.
> >
> > Bob Bell
> >
> > At 10:11 AM  1/6/00, Jonathan Rosenberg wrote:
> > >This is a much different service. As the SIP path and media path are
> > >different (and, in fact, may flow through completely different service
> > >providers), there is really no way for this to be handled at the SIP
> > >layer. A proxy can't know to tear down someone elses call if bandwidth
> > >were available. Even the UA probably can't know that his call is
> > >consuming bandwidth that is preventing some other call from being made.
> > >
> > >Rather, if the *service* we need is that some generals call gets enough
> > >bandwidth, overriding some private, this is best handled by some kind of
> > >diffserv or rsvp operation.
> > >
> > >
> > >-Jonathan R.
> > >
> > >Bob Bell wrote:
> > > >
> > > > Gentlemen -
> > > >
> > > > There is another aspect of MLPP which is being ignored here. That is
> that I
> > > > don't want to talk to you, I just need the bandwidth your
> communications is
> > > > consuming over a WAN link of limited bandwidth. So, I (or a proxy
> which has
> > > > a better network view that I do) needs to tell you that you must
> terminate
> > > > the call. Thus, there is no opportunity for me to present an INVITE
> to you
> > > > and for you to return a Busy indication.
> > > >
> > > > Bob
> > > >
> > > > At 04:50 PM  1/5/00, Adam B. Roach wrote:
> > > >
> > > > >Jonathan Rosenberg writes:
> > > > >
> > > > > >Rather than using this MLPP-Version thing to indicate support for
> CCBS,
> > > > > >I'd rather use the more generic Supported/Require mechanism (a
> draft on
> > > > > >this is pending within the next few days). So,
> > > > > >
> > > > > >C->S INVITE
> > > > > >
> > > > > >S->C 421 Feature Available
> > > > > >Require: com.cisco.mlpp
> > > > > >
> > > > > >C->S INVITE
> > > > > >Supported: com.cisco.mlpp
> > > > > >MLPP: 2;version=1
> > > > > >
> > > > > >S->C 200 OK
> > > > >
> > > > >It sounds like you're adding yet another round trip:
> > > > >the first to agree on the feature, the second to try
> > > > >an invite (which gets a "busy" response), and the third
> > > > >to invoke the feature (am I misreading something here?)
> > > > >
> > > > >Keep in mind that MLPP is relevant only when the far side
> > > > >returns an indication like "busy." Only *after* the calling
> > > > >party is notified that the far side is busy does he make a
> > > > >decision that he wants to break in on the call.
> > > > >
> > > > >Also, in PSTN interoperation scenarios, the gateway won't
> > > > >know that you can break in on the called party until the busy
> > > > >indication arrives (since we're just pumping the call back
> > > > >into the network and don't necessarily know the capability
> > > > >of the end office to which the subscriber is physically
> > > > >connected) -- so negotiation of the feature cannot occur before
> > > > >an attempt is made to reach the called party.
> > > > >
> > > > >If we're going to go out of our way to borrow a service from
> > > > >ISUP, we'd be exceedingly foolish not to make them able to
> > > > >interoperate.
> > > > >
> > > > >--
> > > > >Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho,
> MS
> > > L-04
> > > > >[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX
> > > 75081 USA
> > > > >
> > > >
> > > > Bob Bell
> > > > Cisco Systems Inc.
> > > > 801-294-3034(v)
> > > > 801-294-3023(f)
> > >
> > >--
> > >Jonathan D. Rosenberg                       200 Executive Drive
> > >Chief Scientist                             Suite 120
> > >dynamicsoft                                 West Orange, NJ 07052
> > >[email-masked]                     FAX:   (732) 741-4778
> > >http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > >http://www.dynamicsoft.com
> >
> > Bob Bell
> > Cisco Systems Inc.
> > 801-294-3034(v)
> > 801-294-3023(f)
> 
> --
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jan 2000 08:54:15 -0500

> mention that SIP is the preferred interaction scheme b/w MGC - MGC ?

Its not just a transfer function in this application. The call control
is driven from SIP; the encapsulated data is extra info that can be used
at an ISUP gateway if needed.

The result of this is that you get SIPs powerful proxy, forking, search,
routing, multi-provider, multi-hop  and scaling features, and at the
same time, you get ISUP transparency if you want it. Should an INVITE
with ISUP payloads hit a non-ISUP gateway (or even a PC phone) the data
can be ignored and the call is set up. 

-Jonathan R.