How to leave codecs untachable in sterisk .
For example – i have two accounts on same servers .
Ona account is forced to GSM codec, another – to ULAW.
HOw can i make asterisk not to translate this users?
How to leave codecs untachable in sterisk .
For example – i have two accounts on same servers .
Ona account is forced to GSM codec, another – to ULAW.
HOw can i make asterisk not to translate this users?
for each account in * you can define the codec preference order
ie
disallow=all
allow=ulaw
allow=gsm
allow=ilbc
this disallows all, then allows ulaw,gsm,ilbc in that order of preference. No other codecs are accepted. You could put allow=all at the end to allow all other codecs.
in other words make sure whatever codec you want to use is enabled on both accounts.
also the devices you use must support a common codec. Asterisk will try to avoid translating whenever possible but if either the accounts are set to not use a common codec, or the devices/softphones attached to them are not set to allow a common codec, then asterisk will translate becasue it has no choice.
THATs IT .
How can i deny asterisk to translate in this case ?
I don`t want asterisk to translate codecs in any cases .
Maybe another explanation .
I wand every codecs on the system to act as passthrough.
If i unload all codecs, so i could see only ---- in my show translation. Will all codecs act in passthrough mode?
maybe i found the way to force act asterisk as softswitch. And not to take desigions of codec capabillity.
Today i will check this.
in sip_conf
allow=all
in CLI
show modules like codec
unload … ( here you put modules from 2. )
unload all codecs until you see in CLI>show translations - only -
no no no
Asterisk will try as hard as it can to avoid translating, in every situation. The ONLY situation where asterisk will translate is one where asterisk NOT translating means the call does not go through.
When the call is set up, it tries to find a codec that both parties support. If it does, that codec is used, and is passed through without any doing. The only time * even looks at it is if you have dial options like tT, Rr, etc or features.conf that require * to look for DTMF tones. Either way it does NOT transcode.
Thus, if you set allow=all everywhere, there is the highest chance that a mutual codec will be found. Almost all devices support ulaw or alaw if nothing else, so one of those will probably be picked. With allow=all, codecs are choosen based on what each side of the call asks for. ASTERISK WILL ALWAYS CHOOSE A CODEC BOTH SIDES CAN SUPPORT AND NOT TRANSLATE WHEN A COMMONLY ACCEPTED CODEC IS AVAILABLE. However sometimes it isnt- say one device suppports only ulaw and the other only supports alaw. In this case, there is NO codec that both devices support, and asterisk will translate. However asterisk will try as hard as it can not to let this happen.
So my point is that if you don’t want asterisk to do codec conversion, just allow=all everywhere and make sure your devices aren’t being picky about codecs. Then you are all set.
[quote=“IronHelix”]no no no
Asterisk will try as hard as it can to avoid translating, in every situation. The ONLY situation where asterisk will translate is one where asterisk NOT translating means the call does not go through.
When the call is set up, it tries to find a codec that both parties support. If it does, that codec is used, and is passed through without any doing. The only time * even looks at it is if you have dial options like tT, Rr, etc or features.conf that require * to look for DTMF tones. Either way it does NOT transcode.
[/quote]
A also think so . BUT. NOT NOW.
I make such test.
EYEBEAM ( GSM ) -> asterisk -> EYEBEAM ( ULAW, GSM )
first eyebeam have turned on codec GSM on client side
second eyebeam - GSM and ULAW
On asterisk i put allow=all
then - i start a call. And asterisk start to transkode from gsm to ulaw.
When i unload module codec_gsm and codec_ulaw , my asterisk box sad that there is no path to translate from GSM to ULAW. WHY it is so ?
I put your attention on that fakt that second eyebeam - have two codec turned on on it.
the second eyebeam should list gsm and then ulaw, no? as it is, the first eyebeam negotiates gsm with asterisk (since it only accepts that one codec), and the second eyebeam negotiates ulaw, since asterisk supports both, and will agree on the first both support, hence, asterisk has to transcode. i think changing the second eyebeam to gsm then ulaw should resolve this?
that i the problem .
i mentioned that sip clients sends to server – codec order . but it only defined with my asterisk box. If i put allow=all - all codec orders will be empty.
I thought that eyebeams can фgree with each other and to talk over gsm. And as for me it`s nonsence that one client have GSM, other have ULAW and GSM. And they choose codec not by ligical way. But only with codec order .
But for example I can make eyebeam to put GSM codec before ULAW
THAT is the MOST silly thing in my problem .
I don`t understand .
Evreone is said that asterisk never tries to transcode codecs if it`s possible to send codecs un touchable.
The situation .
server 1 -> asterisk -> server 2
Server 1 - have enabld only GSM codec
server 2 - G729 and GSM
Why asterisk says that it`s not possible to translate codecs when i unload g729 codec?
It`s dammed problem i try to solve.
I think that asterisk is not try to THINK before decide - transcode or not transcode.
HELP ME to solve this problem .
I’m having trouble understanding your english. While the behavior may not make sense to you, it seems you shouldn’t be unloading a codec that you have said ‘allow=’ for. It sounds almost like you want some kind of passthrough negotiation, where asterisk figures out what the two clients each want and somehow use that. If so, it doesn’t work that way. Again, I don’t understand why if you want gsm, you don’t just change the second client to say gsm before ulaw.
you have it right, they should negotiate GSM. Something is preventing them from doing it.
try setting allow=all for both sip peers as well as in [general]. if that doesn’t help do sip debug peer (oneofthepeers) and psot the resulting output
here is my example in work .
First of all - sorry for my english.
I have username 108 with client eyebeam . In sip conf - allow=all . ONLY codec GSM is turned on.
it lives on IP 89.252.1.2
I have username p898984. In sip conf - allow=all . All codec supported.
it lives on ip 91.103.209.10
if i make a call from 108 , asterisk should compare codecs from both sides and choose GSM codec . But it chooses translation from GSM to G729. Here is sip debug.
The same thing if on the other side is eyebeam with G729 and GSM codec.
<-- SIP read from 89.252.1.2:26912:
--- (0 headers 1 lines) ---
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
INVITE sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-e3222a405569bc64-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:108@89.252.1.2:26912>
To: "74957550055"<sip:74957550055@85.91.96.85>
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1006e stamp 33793
Content-Length: 391
v=0
o=- 9 2 IN IP4 192.168.1.100
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.100
t=0 0
m=audio 20460 RTP/AVP 3 101
a=alt:1 3 : NNLRwKlL zRh2NdlD 192.168.1.100 20460
a=alt:2 2 : ZeQ6aqiV Bs6YYNQi 192.168.85.1 20460
a=alt:3 1 : rhw9pUIb crHxaktz 192.168.247.1 20460
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:D7F315287DCC4F5893FBD88E7310B4DC
--- (12 headers 13 lines) ---
Using INVITE request as basis request - ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
Sending to 192.168.1.100 : 26912 (NAT)
Reliably Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-e3222a405569bc64-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as65db538c
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7b6d2d62"
Content-Length: 0
---
Scheduling destruction of call 'ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.' in 15000 ms
Found user '108'
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
ACK sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-e3222a405569bc64-1--d87543-;rport
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as65db538c
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 1 ACK
Content-Length: 0
--- (7 headers 0 lines) ---
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
INVITE sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:108@89.252.1.2:26912>
To: "74957550055"<sip:74957550055@85.91.96.85>
From: "arinos"<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Proxy-Authorization: Digest username="108",realm="asterisk",nonce="7b6d2d62",uri="sip:74957550055@85.91.96.85",response="9a11d7e87d7ea9d7ba9a6c092eae5b15",algorithm=MD5
User-Agent: eyeBeam release 1006e stamp 33793
Content-Length: 391
v=0
o=- 9 2 IN IP4 192.168.1.100
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.100
t=0 0
m=audio 20460 RTP/AVP 3 101
a=alt:1 3 : NNLRwKlL zRh2NdlD 192.168.1.100 20460
a=alt:2 2 : ZeQ6aqiV Bs6YYNQi 192.168.85.1 20460
a=alt:3 1 : rhw9pUIb crHxaktz 192.168.247.1 20460
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:D7F315287DCC4F5893FBD88E7310B4DC
--- (13 headers 13 lines) ---
Using INVITE request as basis request - ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
Sending to 192.168.1.100 : 26912 (NAT)
Found user '108'
Found RTP audio format 3
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.100:20460
Found description format telephone-event
Capabilities: us - 0x1f07ff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x2 (gsm)/video=0x0 (nothing), combined - 0x2 (gsm)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Looking for 74957550055 in default (domain 85.91.96.85)
asterisk*CLI>
list_route: hop: <sip:108@89.252.1.2:26912>
Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Length: 0
---
12 headers, 0 lines
Reliably Transmitting (NAT) to 89.252.1.2:26912:
OPTIONS sip:108@89.252.1.2:26912;rinstance=ad34697761a179a2 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK3e272692;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as5648488d
To: <sip:108@89.252.1.2:26912;rinstance=ad34697761a179a2>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 2bf8d9e410b4f3903dbda14567f683cc@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
---
<-- SIP read from 89.252.1.2:26912:
INVITE sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:108@89.252.1.2:26912>
To: "74957550055"<sip:74957550055@85.91.96.85>
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Proxy-Authorization: Digest username="108",realm="asterisk",nonce="7b6d2d62",uri="sip:74957550055@85.91.96.85",response="9a11d7e87d7ea9d7ba9a6c092eae5b15",algorithm=MD5
User-Agent: eyeBeam release 1006e stamp 33793
Content-Length: 391
v=0
o=- 9 2 IN IP4 192.168.1.100
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.100
t=0 0
m=audio 20460 RTP/AVP 3 101
a=alt:1 3 : NNLRwKlL zRh2NdlD 192.168.1.100 20460
a=alt:2 2 : ZeQ6aqiV Bs6YYNQi 192.168.85.1 20460
a=alt:3 1 : rhw9pUIb crHxaktz 192.168.247.1 20460
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:D7F315287DCC4F5893FBD88E7310B4DC
--- (13 headers 13 lines) ---
Ignoring this INVITE request
Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Length: 0
---
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK3e272692;rport=5060
Contact: <sip:192.168.1.100:26912>
To: <sip:108@89.252.1.2:26912;rinstance=ad34697761a179a2>;tag=3b7d0831
From: "asterisk"<sip:asterisk@85.91.96.85>;tag=as5648488d
Call-ID: 2bf8d9e410b4f3903dbda14567f683cc@85.91.96.85
CSeq: 102 OPTIONS
Accept: application/sdp
Accept-Language: en
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1006e stamp 33793
Content-Length: 0
--- (12 headers 0 lines) ---
Destroying call '2bf8d9e410b4f3903dbda14567f683cc@85.91.96.85'
asterisk*CLI>
-- Executing Set("SIP/108-08327968", "TIMEOUT(absolute)=18750")
-- Channel will hangup at 2007-02-11 15:03:20 UTC.
asterisk*CLI>
12 headers, 0 lines
Reliably Transmitting (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK4816cae3;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as38c8fb2a
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 183e221f4721809d555c13db0b9cd337@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
---
asterisk*CLI>
Retransmitting #1 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK4816cae3;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as38c8fb2a
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 183e221f4721809d555c13db0b9cd337@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
asterisk*CLI>
Retransmitting #2 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK4816cae3;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as38c8fb2a
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 183e221f4721809d555c13db0b9cd337@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
asterisk*CLI>
-- Executing DIAL("SIP/108-08327968", "SIP/74957550055@p898984")
asterisk*CLI>
We're at 85.91.96.85 port 19934
asterisk*CLI>
Adding codec 0x2 (gsm) to SDP
asterisk*CLI>
Adding codec 0x1 (g723) to SDP
asterisk*CLI>
Adding codec 0x4 (ulaw) to SDP
asterisk*CLI>
Adding codec 0x8 (alaw) to SDP
asterisk*CLI>
Adding codec 0x10 (g726) to SDP
asterisk*CLI>
Adding codec 0x20 (adpcm) to SDP
asterisk*CLI>
Adding codec 0x40 (slin) to SDP
asterisk*CLI>
Adding codec 0x80 (lpc10) to SDP
asterisk*CLI>
Adding codec 0x100 (g729) to SDP
asterisk*CLI>
Adding codec 0x200 (speex) to SDP
asterisk*CLI>
Adding codec 0x400 (ilbc) to SDP
asterisk*CLI>
Adding non-codec 0x1 (telephone-event) to SDP
asterisk*CLI>
13 headers, 21 lines
asterisk*CLI>
Reliably Transmitting (no NAT) to 91.103.209.10:5060:
INVITE sip:74957550055@91.103.209.10 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK62bc3bbe;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>
Contact: <sip:108@85.91.96.85>
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 490
v=0
o=root 18642 18642 IN IP4 85.91.96.85
s=session
c=IN IP4 85.91.96.85
t=0 0
m=audio 19934 RTP/AVP 3 4 0 8 111 5 10 7 18 110 97 101
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
---
asterisk*CLI>
-- Called 74957550055@p898984
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK62bc3bbe;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 102 INVITE
Proxy-Authenticate: Digest realm="AlterPSS",nonce="fcbd26025e9a39328affc51af91d38f4",algorithm=MD5
Content-Length: 0
--- (8 headers 0 lines) ---
Transmitting (no NAT) to 91.103.209.10:5060:
ACK sip:74957550055@91.103.209.10 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK62bc3bbe;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Contact: <sip:108@85.91.96.85>
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
We're at 85.91.96.85 port 19934
Adding codec 0x2 (gsm) to SDP
Adding codec 0x1 (g723) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x10 (g726) to SDP
Adding codec 0x20 (adpcm) to SDP
Adding codec 0x40 (slin) to SDP
Adding codec 0x80 (lpc10) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x200 (speex) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 91.103.209.10:5060:
INVITE sip:74957550055@91.103.209.10 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>
Contact: <sip:108@85.91.96.85>
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Proxy-Authorization: Digest username="p898984", realm="AlterPSS", algorithm=MD5, uri="sip:74957550055@91.103.209.10", nonce="fcbd26025e9a39328affc51af91d38f4", response="bced4399c8cb6a9b3671d53e22089702", opaque=""
Date: Sun, 11 Feb 2007 09:50:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 490
v=0
o=root 18642 18643 IN IP4 85.91.96.85
s=session
c=IN IP4 85.91.96.85
t=0 0
m=audio 19934 RTP/AVP 3 4 0 8 111 5 10 7 18 110 97 101
a=rtpmap:3 GSM/8000
a=rtpmap:4 G723/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
---
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Length: 0
--- (7 headers 0 lines) ---
asterisk*CLI>
Retransmitting #3 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK4816cae3;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as38c8fb2a
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 183e221f4721809d555c13db0b9cd337@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
asterisk*CLI>
Retransmitting #4 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK4816cae3;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as38c8fb2a
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 183e221f4721809d555c13db0b9cd337@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:50:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
Destroying call '183e221f4721809d555c13db0b9cd337@85.91.96.85'
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 183 Call Proceeding
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Length: 0
--- (7 headers 0 lines) ---
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 183 Progress
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Type: application/sdp
Content-Length: 169
v=0
o=91.103.209.10 6334 6334 IN IP4 91.103.209.10
s=AlterProxySoftSwitch
c=IN IP4 91.103.209.10
t=0 0
m=audio 22512 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
--- (8 headers 8 lines) ---
Found RTP audio format 18
Peer audio RTP is at port 91.103.209.10:22512
Found description format G729
Capabilities: us - 0x1f07ff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
asterisk*CLI>
-- SIP/p898984-0839ac20 is making progress passing it to SIP/108-08327968
asterisk*CLI>
We're at 85.91.96.85 port 17266
asterisk*CLI>
Adding codec 0x2 (gsm) to SDP
asterisk*CLI>
Adding non-codec 0x1 (telephone-event) to SDP
asterisk*CLI>
Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Type: application/sdp
Content-Length: 213
v=0
o=root 18642 18642 IN IP4 85.91.96.85
s=session
c=IN IP4 85.91.96.85
t=0 0
m=audio 17266 RTP/AVP 3 101
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
---
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Type: application/sdp
Content-Length: 171
v=0
o=91.103.209.10 26500 26500 IN IP4 91.103.209.10
s=AlterProxySoftSwitch
c=IN IP4 91.103.209.10
t=0 0
m=audio 22512 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
--- (8 headers 8 lines) ---
Found RTP audio format 18
Peer audio RTP is at port 91.103.209.10:22512
Found description format G729
Capabilities: us - 0x1f07ff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
-- SIP/p898984-0839ac20 is ringing
Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Length: 0
---
-- SIP/p898984-0839ac20 is making progress passing it to SIP/108-08327968
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
Contact: <sip:74957550055@91.103.209.10>
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Type: application/sdp
Content-Length: 171
v=0
o=91.103.209.10 19169 19169 IN IP4 91.103.209.10
s=AlterProxySoftSwitch
c=IN IP4 91.103.209.10
t=0 0
m=audio 22512 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
--- (9 headers 8 lines) ---
Found RTP audio format 18
Peer audio RTP is at port 91.103.209.10:22512
Found description format G729
Capabilities: us - 0x1f07ff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
list_route: hop: <sip:74957550055@91.103.209.10>
set_destination: Parsing <sip:74957550055@91.103.209.10> for address/port to send to
set_destination: set destination to 91.103.209.10, port 5060
Transmitting (no NAT) to 91.103.209.10:5060:
ACK sip:74957550055@91.103.209.10 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK5c208117;rport
From: "" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Contact: <sip:108@85.91.96.85>
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
-- SIP/p898984-0839ac20 answered SIP/108-08327968
We're at 85.91.96.85 port 17266
Adding codec 0x2 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-fb35737a7967ea03-1--d87543-;received=89.252.1.2;rport=26912
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Type: application/sdp
Content-Length: 213
v=0
o=root 18642 18643 IN IP4 85.91.96.85
s=session
c=IN IP4 85.91.96.85
t=0 0
m=audio 17266 RTP/AVP 3 101
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
---
-- Attempting native bridge of SIP/108-08327968 and SIP/p898984-0839ac20
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
ACK sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-2c35d4096c0cfd0c-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:108@89.252.1.2:26912>
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
From: ""<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 2 ACK
Proxy-Authorization: Digest username="108",realm="asterisk",nonce="7b6d2d62",uri="sip:74957550055@85.91.96.85",response="9a11d7e87d7ea9d7ba9a6c092eae5b15",algorithm=MD5
User-Agent: eyeBeam release 1006e stamp 33793
Content-Length: 0
--- (11 headers 0 lines) ---
asterisk*CLI>
12 headers, 0 lines
Reliably Transmitting (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK10ea64ef;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as6d2b3ee9
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 580ec8036444441c410ddae3594c55b1@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:51:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
---
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
BYE sip:74957550055@85.91.96.85 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-af5bc94d237f2a16-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:108@89.252.1.2:26912>
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
From: "arinos"<sip:108@85.91.96.85>;tag=bb56b93d
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 3 BYE
Proxy-Authorization: Digest username="108",realm="asterisk",nonce="7b6d2d62",uri="sip:74957550055@85.91.96.85",response="3528fe0204ff3298d9ba9fa9f458d4fd",algorithm=MD5
User-Agent: eyeBeam release 1006e stamp 33793
Reason: SIP;description="User Hung Up"
Content-Length: 0
--- (12 headers 0 lines) ---
Sending to 192.168.1.100 : 26912 (NAT)
Transmitting (NAT) to 89.252.1.2:26912:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:26912;branch=z9hG4bK-d87543-af5bc94d237f2a16-1--d87543-;received=89.252.1.2;rport=26912
From: "arinos"<sip:108@85.91.96.85>;tag=bb56b93d
To: "74957550055"<sip:74957550055@85.91.96.85>;tag=as28af7d08
Call-ID: ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
CSeq: 3 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:74957550055@85.91.96.85>
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
---
asterisk*CLI>
Scheduling destruction of call '47fb09ed574ee87b111f623316cf9c25@85.91.96.85' in 32000 ms
set_destination: Parsing <sip:74957550055@91.103.209.10> for address/port to send to
set_destination: set destination to 91.103.209.10, port 5060
Reliably Transmitting (no NAT) to 91.103.209.10:5060:
BYE sip:74957550055@91.103.209.10 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0a28c930;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Contact: <sip:108@85.91.96.85>
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 104 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Proxy-Authorization: Digest username="p898984", realm="AlterPSS", algorithm=MD5, uri="sip:74957550055@91.103.209.10", nonce="fcbd26025e9a39328affc51af91d38f4", response="cb899fa96859e209d2ccae56b890d5dd", opaque=""
Content-Length: 0
---
== Spawn extension (default, 74957550055, 2) exited non-zero on 'SIP/108-08327968'
asterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0a28c930;rport
From: "" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 104 BYE
Content-Length: 0
--- (7 headers 0 lines) ---
Destroying call '47fb09ed574ee87b111f623316cf9c25@85.91.96.85'
asterisk*CLI>
Retransmitting #1 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK10ea64ef;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as6d2b3ee9
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 580ec8036444441c410ddae3594c55b1@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:51:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
asterisk*CLI>
Retransmitting #2 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK10ea64ef;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as6d2b3ee9
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 580ec8036444441c410ddae3594c55b1@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:51:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
Destroying call 'ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.'
asterisk*CLI>
Retransmitting #3 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK10ea64ef;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as6d2b3ee9
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 580ec8036444441c410ddae3594c55b1@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:51:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
asterisk*CLI>
Retransmitting #4 (no NAT) to 91.103.209.9:5060:
OPTIONS sip:91.103.209.9 SIP/2.0
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK10ea64ef;rport
From: "asterisk" <sip:asterisk@85.91.96.85>;tag=as6d2b3ee9
To: <sip:91.103.209.9>
Contact: <sip:asterisk@85.91.96.85>
Call-ID: 580ec8036444441c410ddae3594c55b1@85.91.96.85
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Sun, 11 Feb 2007 09:51:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
asterisk*CLI>
---
Destroying call '580ec8036444441c410ddae3594c55b1@85.91.96.85'
asterisk*CLI>
<-- SIP read from 89.252.1.2:26912:
--- (0 headers 1 lines) ---
asterisk*CLI>
okay whats happening there is asterisk is allowing all codecs for everybody
the sip peer that places the call only supports GSM codec.
the sip peer that recieves the call only supports G.729 codec.
thus asterisk is being given no choice, there are no codecs that both sides support, so it translates.
your solution is with whatever devices you have. One of them is not allowing GSM and the other is not allowing G.729. Asterisk isn’t the problem.
No .
I have two the same EYEBEAMs and one of them configured with codec GSM and another with included codecs - GSM and G729.
You can check by your self that in any case asterisk tryes to translate, because it watch not to the list of the supported codecs – it looks at the sequence of the codecs. Given by client.
nope
call one:
Using INVITE request as basis request - ODg1Yzk1N2M2Mzk4YWEwZDMyYzQzNmVlN2MzZTkwMjA.
Sending to 192.168.1.100 : 26912 (NAT)
Found user '108'
Found RTP audio format 3
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.100:20460
Found description format telephone-event
Capabilities: us - 0x1f07ff
(g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x2 (gsm)/video=0x0 (nothing), combined - 0x2 (gsm)
Note that peer only supports gsm
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Looking for 74957550055 in default (domain 85.91.96.85)
So we have offered everything, peer only offers GSM, so this call leg MUST be GSM as the peer (caller) has offered nothing else.
second call leg is proceeding and sends progress info so we get a SDP:
sterisk*CLI>
<-- SIP read from 91.103.209.10:5060:
SIP/2.0 183 Progress
Via: SIP/2.0/UDP 85.91.96.85:5060;branch=z9hG4bK0934a84e;rport
From: "arinos" <sip:108@85.91.96.85>;tag=as2f17383b
To: <sip:74957550055@91.103.209.10>;tag=24462-775-4167
Call-ID: 47fb09ed574ee87b111f623316cf9c25@85.91.96.85
CSeq: 103 INVITE
Content-Type: application/sdp
Content-Length: 169
v=0
o=91.103.209.10 6334 6334 IN IP4 91.103.209.10
s=AlterProxySoftSwitch
c=IN IP4 91.103.209.10
t=0 0
m=audio 22512 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
note second to last line the only codec offered is g.729. No others.
Now asterisk parses it and spits out the result:
Found RTP audio format 18
Peer audio RTP is at port 91.103.209.10:22512
Found description format G729
Capabilities: us - 0x1f07ff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|jpeg|png|h261|h263|h263p), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
so we (asterisk) offer everything and remote (destination leg) offers only g.729. Thus this leg MUST be g.729.
so we have two call legs. one remote party offered ONLY GSM (first leg), the other offers ONLY g.729 (second leg). Unless of course I am reading this wrong which is certainly possible.
My suggestion would be to look into why eyebeam isnt offering more codecs. However on the latest x-lite i havent been able to find any sort of codec selector so I have no idea where it might be.
[quote=“IronHelix”]
My suggestion would be to look into why eyebeam isnt offering more codecs. However on the latest x-lite i havent been able to find any sort of codec selector so I have no idea where it might be.[/quote]
So as i see it depends on client?
Maybe you can tell me clients which offer more than one codec?
It`s very necessary for me to find the explanation .
As for now - i see that any kind of servers and clients only offers the first codec .
today evening i will try to check how many codecs and in what dependencies - offers asterisk by itself
in your situation i am saying that your eyebeam is only offering g.729 on one side. You could try removing allow=all and ONLY offer GSM on both sides with disallow=all, then allow=gsm, see if it forces eyebeam to use GSM. However it seemed like eyebeam was only offering g.729 so that might make it not work at all.
You should contact counterpath or post on their forums and ask how to manually select the codecs it uses. This feature was present in the old x-lite but i haven’t seen it in the new one. If you figure it out, let me know how.
most servers and clients will offer several codecs, but the ones it offers are based on your selections. So you might be able to choose GSM iLBC ulaw or g.729, and you can enable or disable each one individually.
good luck!
I understand everything . but now we at start of the problem .
I can say , that if i do allow=all
And enable on one side for example GSM codec and from another side codec priority like g729 and GSM. My asterisk don`t try to find codecs – it only become to translate codecs.
no what i am saying is that if you do allow=gsm ONLY (never allow=g729) then asterisk will only offer gsm as a codec option. The client will take it or leave it, and if the client is configured to reject GSM as a codec it will leave it and the call will not go through.
I think that you should contact eyebeam support or post on their forums and ask them how to make sure that GSM codec is enabled…