[Asterisk-Dev] SIP_CODEC still not working in 1.0.1
Andreas Greulich
andreas.greulich at spl.ch
Thu Sep 30 11:03:21 MST 2004
As I already posted in this mailing list for 1.0.0, I still have the problem
that the SIP_CODEC variable doesn't seem to work. It did work in RC2 (so I'm
still using that).
Relevant config:
sip.conf:
[general]
...
context=sip
port=5060
bindaddr=0.0.0.0
srvlookup=yes
[GSIn] ; local phone
type=friend
defaultip=10.1.41.188
context=intern
...
[Sipgate] ; provider
type=friend
host=sipgate.de
disallow=all ; Disallow all codecs
allow=ilbc
...
extensions.conf:
[intern]
exten => h,1,Hangup
exten => _X.,1,SetCallerID(${SIPGATEID})
exten => _X.,2,SetVar(SIP_CODEC=ilbc) ; <<<< that's what it's about!!
Now I make a call from the phone (GSIn) via Asterisk to Sipgate and compare the
2 versions:
The phone first calls Asterisk, in both releases Asterisk "only" has
GSM/ULAW/ALAW/H263:
Capabilities: us - 0x8000e(GSM|ULAW|ALAW|H263), peer -
audio=0x51d(G723|ULAW|ALAW|G726|G729A|ILBC)/video=0x0(EMPTY), combined -
0xc(ULAW|ALAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x0(EMPTY), combined - 0x0(EMPTY)
Both then call the provider (Sipgate) and negotiate to ilbc (no auth needed as
we call a tollfree number):
Reliably Transmitting:
INVITE sip:08003301000 at sipgate.de SIP/2.0
Via: SIP/2.0/UDP 217.162.36.14:5060;branch=z9hG4bK4790c355
From: "1838074" <sip:1838074 at sipgate.de>;tag=as33f18800
To: <sip:08003301000 at sipgate.de>
Contact: <sip:1838074 at 217.162.36.14>
Call-ID: 1de5c3cc4a81df5c56aa0dcb0b090ea7 at 217.162.36.14
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Thu, 30 Sep 2004 17:32:37 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 162
v=0
o=root 4571 4571 IN IP4 217.162.36.14
s=session
c=IN IP4 217.162.36.14
t=0 0
m=audio 14968 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=silenceSupp:off - - - -
...
Sip read:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 217.162.36.14:5060;branch=z9hG4bK4790c355
From: "1838074" <sip:1838074 at sipgate.de>;tag=as33f18800
To: <sip:08003301000 at sipgate.de>;tag=as2cad2e8e
Call-ID: 1de5c3cc4a81df5c56aa0dcb0b090ea7 at 217.162.36.14
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:498003301000 at 217.10.79.30>
Content-Type: application/sdp
Content-Length: 160
v=0
o=root 1179 1179 IN IP4 217.10.79.30
s=session
c=IN IP4 217.10.79.30
t=0 0
m=audio 17846 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=silenceSupp:off - - - -
...
Found description format iLBC
Capabilities: us - 0x400(ILBC), peer - audio=0x400(ILBC)/video=0x0(EMPTY),
combined - 0x400(ILBC)
Non-codec capabilities: us - 0x1(G723), peer - 0x0(EMPTY), combined - 0x0(EMPTY)
-- SIP/Sipgate-da7c is making progress passing it to SIP/GSIn-cc2f
Both answer back to the phone device, initially still with GSM/ULAW/ALAW:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.1.41.188;branch=z9hG4bK14147804d4d8d453
From: <sip:GSIn at 10.1.1.1>;tag=0ec4d9401783a949
To: <sip:00 at 10.1.1.1>;tag=as30e3d88b
Call-ID: 6e0445ae3e8e3589 at 10.1.41.188
CSeq: 53443 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:00 at 10.1.1.1>
Content-Type: application/sdp
Content-Length: 197
v=0
o=root 4571 4571 IN IP4 10.1.1.1
s=session
c=IN IP4 10.1.1.1
t=0 0
m=audio 12436 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
Now the callee picks up the phone, and Sipgate sends an OK.
Now it comes... So far, both releases behaved similar, but here they differ, as
soon as the SIP_CODEC variable was changed in extensions.conf (both perform
this, as the note below shows):
This happens in 1.0 RC2:
Sep 30 19:32:41 NOTICE[294928]: chan_sip.c:1817 sip_answer: Changing codec to
'ilbc' for this call because of ${SIP_CODEC) variable
We're at 10.1.1.1 port 12436
Answering with capability 0x400(ILBC)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.41.188;branch=z9hG4bK14147804d4d8d453
From: <sip:GSIn at 10.1.1.1>;tag=0ec4d9401783a949
To: <sip:00 at 10.1.1.1>;tag=as30e3d88b
Call-ID: 6e0445ae3e8e3589 at 10.1.41.188
CSeq: 53443 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:00 at 10.1.1.1>
Content-Type: application/sdp
Content-Length: 152
v=0
o=root 4571 4572 IN IP4 10.1.1.1
s=session
c=IN IP4 10.1.1.1
t=0 0
m=audio 12436 RTP/AVP 99
a=rtpmap:99 iLBC/8000 <<<<<<<<<<<<<<<<< That's ok!!!!
a=silenceSupp:off - - - -
to 10.1.41.188:5060
-- Attempting native bridge of SIP/GSIn-cc2f and SIP/Sipgate-da7c
-- Attempting native bridge of SIP/GSIn-cc2f and SIP/Sipgate-da7c
Opposed to it, this happens in 1.0.1:
-- SIP/Sipgate-a0b3 answered SIP/GSIn-285d
Sep 30 19:14:10 NOTICE[245775]: chan_sip.c:1853 sip_answer: Changing codec to
'ilbc' for this call because of ${SIP_CODEC) variable
We're at 10.1.1.1 port 19998
Answering with capability 0x2(GSM)
Answering with capability 0x4(ULAW)
Answering with capability 0x8(ALAW)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.41.188;branch=z9hG4bK508e666cda524530
From: <sip:GSIn at 10.1.1.1>;tag=bec21ba9e2c638f5
To: <sip:00 at 10.1.1.1>;tag=as1e1c9d3f
Call-ID: 26ca9bc8cd4a4982 at 10.1.41.188
CSeq: 53206 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:00 at 10.1.1.1>
Content-Type: application/sdp
Content-Length: 197
v=0
o=root 2744 2745 IN IP4 10.1.1.1
s=session
c=IN IP4 10.1.1.1
t=0 0
m=audio 19998 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000 <<<<<<<<<<<<<<<<< should be ilbc!!!!
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
to 10.1.41.188:5060
-- Attempting native bridge of SIP/GSIn-285d and SIP/Sipgate-a0b3
Consequently, "sip show channels" in 1.0 RC2:
rufus*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format
217.10.79.9 0800330100 1de5c3cc4a8 00102/00000 ILBC
10.1.41.188 GSIn 6e0445ae3e8 00101/53443 ILBC
2 active SIP channel(s)
and in 1.0.1:
rufus*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format
217.10.79.9 0800330100 4dceed4d2f1 00102/00000 ILBC
10.1.41.188 GSIn 26ca9bc8cd4 00101/53206 ULAW
2 active SIP channel(s)
As far as I interpret this, this still looks as a bug.
--
Andreas Greulich
E-Mail: andreas.greulich at spl.ch
Skype: klaymen-neverhood
Sermo datur cunctis, animi sapientia paucis.
More information about the asterisk-dev
mailing list