Subject: [SIP] RE: [Sip-implementors] Clarification on sdp usage sought

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 11:44:00 -0400

Moving this to SIP, since its a bigger issue.	

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2001 2:30 PM
> Cc: [email-masked]
> Subject: Re: [Sip-implementors] Clarification on sdp usage sought
> 
> > 
> > 
> > However, it is JUST ADVISORY. 
> > 
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > Receivers need to be prepared to receive any number of 
> frames per packet.
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> This is easier said than done. Take G.729 for example. If an 
> implementation supports the base frame size (10ms), then I agree that 
> any number of frames per packet can be supported because a 
> multi-frame  
> RTP packet can always be sliced up. However, the 10ms frame 
> size may not 
> be suitable for some implementations (due to, say, too many 
> interrupts 
> from the DSP. I assume DSPs here again.) So you may have an 
> implementation that can only support nx20ms, or nx30ms G.729. 
>  In other 
> cases, you have implementations that can support nx10 ms 
> G.729 but the 
> size has to be preconfigured (because, say, trade-offs have 
> to be made 
> here and different DSP codes have to be loaded in the DSPs.) 
> We've seen 
> a lot of these cases in past SIP bake-offs and H323 events.

Right. And these are causing interoperability failures. Thats why you need
to deal with this properly, and be prepared to receive any number of frame
sizes. If you want to get larger packetizations in order to reduce DSP
interrupts, then send a ptime with some larger value in the SDP. But, its
only advisory. You must be prepared to receive any number. Its what rfc1889
says. Its what the update to rfc1889 says. Its there for a reason.

> 
> One may argue that the 20ms or 30ms G.729 is really not G.729 
> compliant. 
> But let's be practical here. The only thing you lose by 
> doubling G.729 
> frame size from 10ms to 20ms is additional 10ms one-way delay, which 
> obviously is not a big deal for VoIP applications.

Apparently, the problem is that we are losing interoperability.

> 
> What about non-frame based codecs -- G.711 A/u-law? I believe 
> the "frame 
> size" is defined (in RFC???) to be 1 ms. But I have yet to see one 
> DSP-based implementation that can operate G.711 on 1ms granularity.

Realistically, no one is ever going to send that fast, and you can send
ptime as an advisory to tell them not to send that fast. If they do anyway,
hang up. But, your code must support any number of samples per packet. Thats
not just a spec requirement, its good software design. 

> 
> All in all, let me repeat what I said above:We need something 
> in SDP to 
> support this application -- codec specific packetization size.

No, what we need is for people to actually implement the specifications
correctly. Supporting the various nuances of all the different constraints
an implementation might introduce is a road to interoperability nightmares
and complexity. What if some implementation can do 20ms G.729 when a video
codec is running, but 10ms otherwise? Shall we support that? What if another
implementation supports 30ms G.729 when H.263 with B frames is running, in
conjunction with silence suppression, but if there is no video, and only
silence suppression, it does 20ms, and if nothing else, 10ms. Shall we
support that too?

We have taken the approach with SIP to keep it simple, and keep it general.
I think we should stick with that approach.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Shan Lu <[email-masked]>
Date: Wed, 25 Apr 2001 17:37:16 -0400

Jonathan Rosenberg wrote:

-----Original Message-----
From: Shan Lu [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 2:30 PM
Cc: [email-masked]
Subject: Re: [Sip-implementors] Clarification on sdp usage sought

frames per packet.

-Jonathan R.

When you design a protocol, you make some assumptions. In this case, the
assumption is that once an implementation indicates G.729 capability, then
it must support any number of base G.729 frames in a packet.  As evidenced
by past SIP and H323 interoperability events, this assumption is not true.
And we can rest assured that if one can find  implementations at these testing
events that do not have the  "any frame size" capability, there will be many
more products out there with the same problem. Now you have two options:
1. Make necessary changes in the protocol to accommodate the reality.  2.
Make no changes and ignore the problem.

If we choose Option #2, one can be certain that the problem or the "faulty"
implementations will not go away.  What we will end up with is that either
the deployment is comprised of only one vendor or when multiple vendors are
involved, the configurations have to be "tweaked", which is exactly how we
got around the problem at Bake-offs.  Will it work? Maybe. But surely not
very desirable.

While we are at it, let's also discuss other SDP issues. The one proposal
on the table allows more than more codec in the responding SDP (200OK or
ACK). This could easily lead to different codecs being used for transmit
and receive. If you take the same approach as the frame size issue, you may
assume that if an implementation advertises 3 codecs, it must be able to
transmit and receive on any combination of the codecs, which is even more
problematic in my view.

I am not saying that we need to complicate the protocol so much to accommodate
every single implementation constraint. But for common, known implementation
limitations, such as frame size and symmetric operation, we must come up
with a way to cope with.

Regards,

Shan Lu

NexTone Communications