[asterisk-bugs] [JIRA] (ASTERISK-25656) No Codec in 183 with Chan SIP and Asterisk 13 when Recoding Required

Peter Sokolov (JIRA) noreply at issues.asterisk.org
Tue Jan 5 11:25:33 CST 2016


    [ https://issues.asterisk.org/jira/browse/ASTERISK-25656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228837#comment-228837 ] 

Peter Sokolov commented on ASTERISK-25656:
------------------------------------------

Yes, I mean transcoding from alaw to g722. Asterisk 13 seems to like to transcode as often as possible even if both SIP endpoints support exactly the same codecs. Previous Asterisk versions passed RTP without transcoding directly peer-to-peer almost always when possible. The problem described here however occurs in the case when transcoding from alaw to g722 is really required.

To reproduce, configure like below. 333 is a SIP phone (FritzBox in my case) that supports g722 and alaw. OutTrunk is a SIP trunk provider that does not support g722 for calls out of its network (it replies with alaw only in 183 SDP). It seems to be important that both peers are set to directmedia=yes in a way that in the case of both supporting the same codec, RTP flows directly between them.

Make a call from peer 333 to a number that is routed through OutTrunk. When OutTrunk sends 183 with only alaw in SDP, you should see that Asterisk sends 183 without voice codecs in SDP to peer 333. My SIP device cancels the call in that case. Maybe some devices will not cancel the call, but the will not get information about the codec for early media, which certainly is not correct.

Just extending the config of the peer 333 to allow=g722,alaw will cause the Asterisk to include both codecs (g722 and alaw) in the SDP of 183. It will also translate received alaw early media from the peer OutTrunk to g722 and send it to peer 333. Asterisk versions before 13 in that case did not intend to pass early media through Asterisk and did let alaw early media flow directly from peer OutTrunk to peer 333 without transcoding to g722 (this unnecessary transcoding is however not the problem I am reporting here).

{code}
sip.conf:
[333]
type=friend
context=users
subscribecontext=users
secret=donttell
language=de
mailbox=333 at default
host=dynamic
dtmfmode=rfc2833
defaultuser=333
callerid=333 <00333>
restrictcid=no
fromdomain=test.tst
directmedia=yes
nat=no
insecure=port
call-limit=5
allowsubscribe=yes
disallow=all
allow=g722

[OutTrunk]
type=peer
fromdomain=test2.tst
defaultuser=user1
secret=donttell
host=test2.tst
context=users
directmedia=yes
qualify=no
insecure=port,invite
promiscredir=no
dtmfmode=rfc2833
nat=no
disallow=all
allow=g722,alaw
callgroup=1
t38pt_udptl=no
t38pt_rtp=no
t38pt_tcp=no

extensions.conf:
[users]
exten => 123,1,NoOp
exten => 123,n,Set(CALLERID(number)=00333)
exten => 123,n,Set(CALLERID(name)=${CALLERID(number):2})
exten => 123,n,Set(CALLERID(number)=${CALLERID(number):2})
exten => 123,n,Dial(SIP/${EXTEN}@OutTrunk,60,)
exten => 123,n,Hangup
{code}

> No Codec in 183 with Chan SIP and Asterisk 13 when Recoding Required
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-25656
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25656
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.7.0
>         Environment: Debian 8.2
>            Reporter: Peter Sokolov
>            Assignee: Peter Sokolov
>
> When the only way to establish the communication between two SIP devices is recoding, the 183 reply does not contain any voice codecs, causing the calling device to cancel the call, making it impossible to establish a call between the two devices.
> In the following example the originating SIP device (333 at test.tst) has only configured allow=g722 in sip.conf. The destination device has configured allow=g722,alaw, but replies with 183 containing alaw only. Asterisk 13.7.0-rc2 sends the 183 to the originating device, indicating no voice codecs at all, although it is capable to translate from alaw to g722. The originating device cancels the call. No "Adding codec" is visible in the SIP log between receiving the 183 and sending 183.
> {code}
> <--- SIP read from UDP:X.X.X.X:5060 --->
> INVITE sip:123 at test.tst SIP/2.0
> Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKB37C778E1ADC60AE
> From: <sip:333 at test.tst>;tag=8AF3B60254E4CDF1
> To: <sip:123 at test.tst>
> Call-ID: 2C3F4CB345A924C9 at 192.168.0.30
> CSeq: 3394 INVITE
> Contact: <sip:333 at X.X.X.X:5060;uniq=C465CA211E8EEE061CD248D47C840>
> Max-Forwards: 70
> Expires: 120
> User-Agent: AVM FRITZ!Box 7490 113.06.50 (Dec 4 2015)
> Supported: 100rel,replaces
> Allow-Events: telephone-event,refer
> Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
> Content-Type: application/sdp
> Accept: application/sdp, multipart/mixed
> Accept-Encoding: identity
> Content-Length: 431
> v=0
> o=user 16478182 16478182 IN IP4 X.X.X.X
> s=call
> c=IN IP4 X.X.X.X
> t=0 0
> m=audio 7078 RTP/AVP 9 8 0 2 102 100 99 101 97 120 121
> a=sendrecv
> a=rtpmap:2 G726-32/8000
> a=rtpmap:102 G726-32/8000
> a=rtpmap:100 G726-40/8000
> a=rtpmap:99 G726-24/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=30
> a=rtpmap:120 PCMA/16000
> a=rtpmap:121 PCMU/16000
> a=rtcp:7079
> a=ptime:30
> <------------->
> --- (18 headers 19 lines) ---
> Sending to X.X.X.X:5060 (no NAT)
> Using INVITE request as basis request - 2C3F4CB345A924C9 at 192.168.0.30
> Found peer '333' for '333' from X.X.X.X:5060
>   == Using SIP RTP CoS mark 5
> Found RTP audio format 9
> Found RTP audio format 8
> Found RTP audio format 0
> Found RTP audio format 2
> Found RTP audio format 102
> Found RTP audio format 100
> Found RTP audio format 99
> Found RTP audio format 101
> Found RTP audio format 97
> Found RTP audio format 120
> Found RTP audio format 121
> Found audio description format G726-32 for ID 2
> Found audio description format G726-32 for ID 102
> Found unknown media description format G726-40 for ID 100
> Found unknown media description format G726-24 for ID 99
> Found audio description format telephone-event for ID 101
> Found audio description format iLBC for ID 97
> Found unknown media description format PCMA for ID 120
> Found unknown media description format PCMU for ID 121
> Capabilities: us - (g722), peer - audio=(ulaw|g726|alaw|g722|ilbc)/video=(nothing)/text=(nothing), combined - (g722)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port X.X.X.X:7078
> Looking for 123 in users (domain test.tst)
> sip_route_dump: route/path hop: <sip:333 at X.X.X.X:5060;uniq=C465CA211E8EEE061CD248D47C840>
> <--- Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 100 Trying
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKB37C778E1ADC60AE;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=8AF3B60254E4CDF1
> t: <sip:123 at test.tst>
> i: 2C3F4CB345A924C9 at 192.168.0.30
> CSeq: 3394 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> l: 0
> <------------>
>     -- Executing [123 at users:1] NoOp("SIP/333-000000af", "") in new stack
>     -- Executing [123 at users:2] Set("SIP/333-000000af", "CALLERID(number)=00333") in new stack
>     -- Executing [123 at users:3] Set("SIP/333-000000af", "CALLERID(name)=333") in new stack
>     -- Executing [123 at users:4] Set("SIP/333-000000af", "CALLERID(number)=333") in new stack
>     -- Executing [123 at users:5] Dial("SIP/333-000000af", "SIP/123 at OutTrunk,60,") in new stack
>   == Using SIP RTP CoS mark 5
> Audio is at 17520
> Adding codec g722 to SDP
> Adding codec alaw to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (no NAT) to D.D.D.D:5060:
> INVITE sip:123 at test2.tst SIP/2.0
> v: SIP/2.0/UDP A.A.A.A:5060;branch=z9hG4bK57ab5e3d
> Max-Forwards: 70
> f: "333" <sip:333 at test2.tst>;tag=as0b8f7499
> t: <sip:123 at test2.tst>
> m: <sip:333 at A.A.A.A:5060>
> i: 7d2574bb50b5acc455fb91ff6859d6a9 at test2.tst
> CSeq: 102 INVITE
> User-Agent: Asterisk
> Date: Sun, 03 Jan 2016 17:11:35 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> c: application/sdp
> l: 278
> v=0
> o=root 1839661651 1839661651 IN IP4 X.X.X.X
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 X.X.X.X
> t=0 0
> m=audio 7078 RTP/AVP 9 8 101
> a=rtpmap:9 G722/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> ---
>     -- Called SIP/123 at OutTrunk
> <--- SIP read from UDP:D.D.D.D:5060 --->
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 172.31.1.100:5060;branch=z9hG4bK57ab5e3d
> From: "333" <sip:333 at test2.tst>;tag=as0b8f7499
> To: <sip:123 at test2.tst>
> Contact: sip:123 at D.D.D.D:5060
> Call-ID: 7d2574bb50b5acc455fb91ff6859d6a9 at test2.tst
> CSeq: 102 INVITE
> Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
> Content-Length: 0
> <------------->
> --- (10 headers 0 lines) ---
> <--- SIP read from UDP:D.D.D.D:5060 --->
> SIP/2.0 183 Session progress
> Via: SIP/2.0/UDP 172.31.1.100:5060;branch=z9hG4bK57ab5e3d
> From: "333" <sip:333 at test2.tst>;tag=as0b8f7499
> To: <sip:123 at test2.tst>;tag=3a0313ac55f03691abedc0
> Contact: sip:123 at D.D.D.D:5060
> Call-ID: 7d2574bb50b5acc455fb91ff6859d6a9 at test2.tst
> CSeq: 102 INVITE
> Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
> Content-Type: application/sdp
> Content-Length: 210
> v=0
> o=CARRIER 1451841145 1451841145 IN IP4 D.D.D.D
> s=SIP Call
> c=IN IP4 D.D.D.D
> t=0 0
> m=audio 36114 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=ptime:20
> a=sendrecv
> <------------->
> --- (11 headers 10 lines) ---
> sip_route_dump: route/path hop: <sip:0000038659207726 at D.D.D.D:5060>
> Found RTP audio format 8
> Found RTP audio format 101
> Found audio description format PCMA for ID 8
> Found audio description format telephone-event for ID 101
> Capabilities: us - (g722|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port D.D.D.D:36114
>     -- SIP/OutTrunk-000000b0 is making progress passing it to SIP/333-000000af
> Audio is at 10768
> Adding non-codec 0x1 (telephone-event) to SDP
> <--- Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 183 Session Progress
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKB37C778E1ADC60AE;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=8AF3B60254E4CDF1
> t: <sip:123 at test.tst>;tag=as60d85cd4
> i: 2C3F4CB345A924C9 at 192.168.0.30
> CSeq: 3394 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> c: application/sdp
> l: 203
> v=0
> o=root 2018919976 2018919976 IN IP4 D.D.D.D
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 D.D.D.D
> t=0 0
> m=audio 36114 RTP/AVP 101
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
> <------------>
> <--- SIP read from UDP:X.X.X.X:5060 --->
> CANCEL sip:123 at test.tst SIP/2.0
> Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKB37C778E1ADC60AE
> From: <sip:333 at test.tst>;tag=8AF3B60254E4CDF1
> To: <sip:123 at test.tst>
> Call-ID: 2C3F4CB345A924C9 at 192.168.0.30
> CSeq: 3394 CANCEL
> Reason: SIP; cause=488; text="SDP problem"
> Max-Forwards: 70
> User-Agent: AVM FRITZ!Box 7490 113.06.50 (Dec 4 2015)
> Supported: 100rel,replaces
> Allow-Events: telephone-event,refer
> Content-Length: 0
> {code}
> Modifying the codecs to allow=g722,alaw for the originating device in sip.conf causes Asterisk to indicate both codecs (g722 and alaw) in 183 and it happily translates received alaw early media to g722 and sends it to the originating device. Two "Adding codec" are visible in the SIP log between receiving the 183 and sending 183. So adding a codec which would not need translation, but is not used in that call at all, causes Asterisk to add also the codec that needs translation to SDP in 183.
> {code}
> Found RTP audio format 8
> Found RTP audio format 101
> Found audio description format PCMA for ID 8
> Found audio description format telephone-event for ID 101
> Capabilities: us - (g722|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> Peer audio RTP is at port D.D.D.D:11742
>     -- SIP/OutTrunk-000000b0 is making progress passing it to SIP/333-000000af
> Audio is at 11122
> Adding codec g722 to SDP
> Adding codec alaw to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> <--- Transmitting (no NAT) to X.X.X.X:5060 --->
> SIP/2.0 183 Session Progress
> v: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK4BDDDB221D20FE39;received=X.X.X.X
> f: <sip:333 at test.tst>;tag=804A2A9B6FD4EF6D
> t: <sip:123 at test.tst>;tag=as01c742c2
> i: 6ED3E4C17715F952 at 192.168.0.30
> CSeq: 3394 INVITE
> Server: Asterisk
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> k: replaces, timer
> m: <sip:123 at A.A.A.A:5060>
> c: application/sdp
> l: 203
> v=0
> o=root 2040737164 2040737164 IN IP4 A.A.A.A
> s=Asterisk PBX 13.7.0-rc2
> c=IN IP4 A.A.A.A
> t=0 0
> m=audio 36114 RTP/AVP 9 8 101
> a=rtpmap:9 G722/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list