[Asterisk-Users] Sip to Sip Calls via Asterisk

[David Allen]

Hi All,

    I have a weird problem. I have asterisk setup using the G729 Codec to
receive Incoming calls both from a SIP Gateway (SER and Quintum) and via
ISDN using i4l and have rules setup in extensions.conf for sending calls out
either back via the SIP Gateway or ISDN. What I want to do is have PSTN
calls come in via the SIP Gateway, be answered by the auto-attendant and
then sent back out to the SIP Gateway to a PSTN number when the particular
choice is made. However it gets to the point of ringing and then once the
call is connected, there is no voice traffic and the following message
appears:

chan_sip.c:2752 process_sdp: No compatible codecs!

(Only if multiple codecs are available on the SER server) otherwise if I
only have one codec allowed on the Quintum and Asterisk, it does not come up
with this error (eg G729 or ALAW). However if you ring in from the PSTN (via
ISDN) and select this option, it completes the call as requested, the same
if I call the menu and select the option from a ip phone connected directly
to the Asterisk Box.

These Configurations work fine (In Easy step through):

Incoming Call from ISDN --> Asterisk Menu --> Selection Made --> Call sent
out to SER/Quintum --> Connected Party
Incoming Call from local IP Phone --> Asterisk Menu --> Selection Made -->
Call sent out to SER/Quintum --> Connected Party
Incoming Call from SER from IP Phone --> Asterisk Menu --> Selection
Made --> Call sent out to SER/Quintum --> Connected Party

This doesn't work:
Incoming Call from SER/Quintum from PSTN --> Asterisk Menu --> Selection
Made --> Call sent out to SER/Quintum --> Connected Party

Everything looks ok here and the configuration is correct (when I can make
calls out to the SIP Gateway, both from mentioned earlier and from the IP
Phone.) It appears that its only effecting incoming calls coming in from the
Quintum from the PSTN to the SER gateway and then to asterisk, which are
then being sent back out the SER gateway to the quintum to carry the call
back to the PSTN.

Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.20:5060;branch=z9hG4bK39591ff8;rport=5060
To: <sip:98009800 at 192.168.1.90>;tag=1bc039ff
From: "0388016766" <sip:0388016766 at 192.168.1.90>;tag=as34cebb79
Call-ID: 71e3976d3e5dffcf3f0eda5b6ecd4b89 at 192.168.2.20
CSeq: 104 INVITE
Record-Route: <sip:98009800 at 192.168.1.90;ftag=as34cebb79;lr>
Contact: <sip:98009800 at 192.168.1.90:5061>
Content-Type: application/sdp
Content-Length: 207

v=0
o=Quintum 13544 2493 IN IP4 192.168.1.90
s=VoipCall
c=IN IP4 192.168.1.90
t=0 0
m=audio 10672 RTP/AVP 18 101
c=IN IP4 192.168.1.90
a=rtpmap:18 g729/8000/1
a=rtpmap:101 telephone-event/8000/1

10 headers, 9 lines
Found RTP audio format 18
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.90:10672
Found description format g729
Found description format telephone-event
Capabilities: us - 0x108(ALAW|G729A), peer -
audio=0x100(G729A)/video=0x0(EMPTY), combined - 0x100(G729A)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined -
0x1(G723)
set_destination: Parsing <sip:9800900 at 192.168.1.90;lr> for address/port to
send to
set_destination: set destination to 192.168.1.90, port 5060
Transmitting:
ACK sip:98009800 at 192.168.1.90:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.20:5060;branch=z9hG4bK3fd2c533;rport
Route: <sip:98009800 at 192.168.1.90:5061>
From: "0388016766" <sip:0388016766 at 192.168.1.90>;tag=as34cebb79
To: <sip:98009800 at 192.168.1.90>;tag=1bc039ff
Contact: <sip:98009800 at 192.168.2.20>
Call-ID: 71e3976d3e5dffcf3f0eda5b6ecd4b89 at 192.168.2.20
CSeq: 104 ACK
User-Agent: Asterisk PBX
Content-Length: 0

 (NAT) to 192.168.1.90:5060

The strange thing is that when this happens it appears that the RTP stream
is stable and there is no indication of problems in selecting the codecs. Is
there any possible cause as to why this may happen? Especially when it works
correctly when I make a call in via the ISDN or an IP phone connected to the
Asterisk Server. Does anyone have any pointers as to what may be causing
this problem?

Thanks,

David