[Asterisk-Dev] Asterisk behaviour in codec negoiation and for reinvites

[chrisast at talisa.net]

Hi guys,

I'm working to get some firmware fixed and am talking to the developers /
programmers of the firmware. (and a bit out of my depth)

They are commenting on the way that * does CODEC negoiation for SIP and
also asking how reinvites should be done ideally to make their hardware
compatible with Asterisk.

These are probably trivial details to you but I don't know if what they
are saying is right or how what an ideal situation would be or what the
developers of asterisk would like the hardware to do to make their life
easier.

I'm afraid I'm a little out of my depth here but I'd love to get the
firmware fixed.  Is there any chance someone could tell me the answers
they want to the below so I can send an appropriate reply as I've been
pulling my hair out for months with this (otherwise great) hardware
(Draytek 2600V) and now that I've finally got the developer / person who
wrote the firmware by email to reply I'd love to get these things fixed.

I think they've already fixed the hangup bug for this hardware and so
with it an immediate need for SIP session timers.

If there are any other questions or comments you think I should ask or put
to them please let me know.

Thanks for considering helping to make this device compatible with *
The server they refer to is an asterisk server running last nights CVS
that they have been talking SIP to.

in my sip.conf in the general section I have

allow=gsm    ; very cool and supported by the snom
allow=g729   ; proprietary but cool
allow=alaw   ; no bridging/clicking hassle with alaw
allow=g726   ; seems to work now in CVS
allow=ulaw   ; can be translation hassles but needed by fwd and the USA
allow=ilbc   ; just for good measure though don't know any h/w that
supports

(assuming gsm would be preferred - is it the other way up ?)

Their question is below :

(Background:

There was a problem as I have allow=ilbc and this confused their hardware
initially.

- * complained about ilbc frame size, 

I assume as it wasn't ilbc they were sending as they don't support it.
I mention it as they allege the rabbit hole may go deeper and that they
way Asterisk replies may be wrong? I don't know what should happen ?

With reinvites asterisk stayed in the middle for the voice stream rather
than letting the units talk amongst themselves with reinvite)
They want to know 'ideal behaviour'

Really hope you can help, I know you're mad busy though, just a few lines
of example would be amazing.

Chris

------------------------------
Hi Chris,

The normal SDP negotiation process is:

1. Caller sends INVITE + SDP , and lists all the CODECs the device can
support
2. Callee replies 200 OK + SDP, lists the matching CODECs with caller's
list, and puts the preferred CODEC in first place.
3. Caller picks the first CODEC in callee's SDP and sets up
the DSP for whichever CODEC will be used.

In your server's scenario, the server as a callee lists all the CODECs it
supports in the SDP, so the caller will not know which one the server
would like to use; and the worse thing is that it puts a non-supported
CODEC to the caller in the first place; so our old firmware did not know
how do handle this situation.

After we changed our code to choose one _supported_ CODEC in the callee's
list, it now can work already. 

But, I can still hear a short period of noise at the beginning of the RTP
session build up before your smart server knows which CODEC the caller
would like to use.

I'm not comfortable with this behavior, because it generates a short
period of noise in the begining of the voice stream. However, I can
accept it if you are not changing it!

About the re-invite, could you send me a successful log to understand the
scenario; we'll do more testing with this issue!