Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading)

From: [email-masked]
Date: Tue, 19 Mar 2002 07:14:42 +0200

Hi,

Right. And fortunately there are some sub-IP mechanisms in place to separate RTP and SIP and even do L2 fragmentation so that a large SIP IP-packet won't block RTP. Mid-call signaling was also one of the reasons to start developing SigComp.

What I'm more worried is the prioritization of SIP vs. SIP, i.e. handling of call setup signaling compared to messaging or presence or whatever SIP will be used next for. That logic needs to reside in the application layer, as for e.g. DiffServ classifiers all SIP looks the same. 

The list of reasons is this:
- SIP call setup budget with manyfolks and resource reservation over low-capacity wireless will be tight even with SigComp. It must be possible to separate this traffic from other SIP traffic, e.g. messages.
- This is especially true when thinking about emergency services. 
- Some operators want to separate call setup traffic from other traffic also for charging reasons (no volume-based charging for "signaling"). This is done by having counters on SIP traffic. It must be possible to separate SIP call setup signaling from other SIP traffic for this reason as well.

I'm not sure if there is anything to standardize for SIP though. In the simplest case this could be seen as a policy issue for SIP UAs and proxies, so that they would mark different SIP packets differently (for example with different DS codepoints). These just need to be configured right in proxies and routers. So this may be an additional(?) requirement to SIP device configuration. But maybe someone has a clearer view.

Markus

> -----Original Message-----
> From: ext Dean Willis [mailto:[email-masked]]
> Sent: 15 March, 2002 21:16
> To: Ben Campbell; Isomaki Markus (NRC/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Simple] Messages: Signaling, Data, or Theft
> (Wassomethingto do wit message threading)
> 
> 
> 
> Actually, if you do the math, you find that something like 64 
> bytes is 
> the largest message size whose serialization delay doesn't 
> break RTP at 
> 9600 bps. That makes it a sub-IP interrleaving problem.
> 
> --
> Dean
> 
> 
> On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote:
> > > Also a question: what if there is a single TCP connection between
> > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > > In the meanwhile an INVITE for a voice call arrives at the proxy
> > > to be delivered to the same UA. Is it possible to interleave it
> > > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > > the transport?
> >
> > That could be a problem in some scenarios. I think the real answer,
> > though, is to limit the MESSAGE requests to some reasonable size. We
> > have had talk about standardizing methods to send large data by
> > reference--I think any real application that sends messages
> > containing much bigger than an average text IM will eventually need
> > to go that route.
> >
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>