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! _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
