[Asterisk-Users] Asterisk / Quintum CRSP codec problems

Pavel Siderov pi at hostmates.com
Wed Apr 13 05:11:32 MST 2005


Hi Guys, 

I have following scenario which causes an issue related to codecs (please look below)

[asterisk] -> Quintum CRSP* / Quintum CMS -> PSTN 

* Quintum Call Relay SP (CRSP - http://www.quintum.com/main/servproducts.html?id=15), Quintum CMS - H323 based gateway

When a call is being placed using a SIP client, UAC (sip client) sends a list of supported codecs  to the asterisk and combined list is build as supposed, 

e.g.

Capabilities: us - 0x10d (g723|ulaw|alaw|g729), peer - audio=0x10e (gsm|ulaw|alaw|g729)/video=0x0 (nothing), combined - 0x10c (ulaw|alaw|g729)


My Asterisk has following codec settings applied:

disallow=all
allow=g723
allow=g729
allow=alaw
allow=ulaw

Asterisk forwarding calls with prefix 00 to Quintum SIP-PSTN (Quintum CRSP) gateway which has enabled g723,g729, ulaw and alaw codecs - the same as ones on the asterisk side. 

Quintum CRSP sends back only the first codec out of the supported codecs list on my side (asterisk) and within the combined list there is only the first codec on asterisk side. Please find below log out of described above behaviour:

Sip read:
SIP/2.0 200 OK
CSeq: 102 INVITE
Call-ID: 4334482065fd376d226204fe4cdd3722 at 5.6.7.8
Contact: <sip:35923456 at 1.2.3.4>
Content-Type: application/sdp
From: "pavel"<sip:765 at 5.6.7.8:5060>;tag=as74cec9db
To: <sip:35923456 at 1.2.3.4>;tag=3ef4af85-1112b
Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK5568aa34
Content-Length: 168
User-Agent: Quintum/1.0.0

v=0
o=Quintum 33034 31527 IN IP4 1.2.3.4
s=VoipCall
c=IN IP4 1.2.3.4
t=0 0
m=audio 10858 RTP/AVP 4
c=IN IP4 1.2.3.4
a=rtpmap:4 g723/8000/1

10 headers, 8 lines
Found RTP audio format 4
Peer audio RTP is at port 1.2.3.4 :10858
Found description format g723
Capabilities: us - 0x10d (g723|ulaw|alaw|g729), peer - audio=0x1 (g723)/video=0x0 (nothing), combined - 0x1 (g723)

where us is asterisk, peer is the Quintum CRSP

This way if the SIP client supports only G729 the call fails since the combined list of codecs would be again g723 as long as the g729 is not the first in the list of asterisk's codecs.

Is there any way I can forcably determine the codecs reported for the peer out of the asterisk's codec capabilities list?

Any idea how I could force the asterisk to change the order of supported codecs according to the SIP client first codec in the list or how I could force the Quintum to send back the full list of supported codecs  ?

Thanks and regards,

Pavel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050413/c0e29f94/attachment.htm


More information about the asterisk-users mailing list