[Home]

Summary:ASTERISK-18410: Defining same SIP device as user/friend and peer
Reporter:Fabian Borot (fborot)Labels:
Date Opened:2011-09-02 14:57:26Date Closed:2011-09-08 11:45:59
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.3 1.8.5.0 Frequency of
Occurrence
Related
Issues:
Environment:Linux asterisk1-8.lab.com 2.6.18-238.el5 #1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64 x86_64 x86_64 GNU/LinuxAttachments:
Description:Up to version 1.6.0.3-rc1 we were able to configure the same SIP device as a user or friend (for inbound calls) and also as a peer (no context and for outbound calls only). Now on version 1.8.3 and 1.8.5 (those are the ones I have been working on) we can not do it because when the INVITE comes the function "find_peer" on "chan_sip.c" returns the peer instead of the user/friend. Then since the peer has no context asterisk tries to find the  extension on the "default" context and it fails because there is no logic on that context. I posted this question on the asterisk.org forum and was told that for "users" asterisk uses the "From" header, not the IP and for "peers" it uses the IP. I don't know for long this has been the case but up to version "1.6.0.3-rc1" this setup works fine 100%. This is the reason why we use this setup:

For example with these entries on sip.conf:(same trunk but with different codecs)

[carrier-1]
type=user;or friend
host=192.168.1.200
dtmfmode=rfc2833
insecure=invite
disallow=all
allow=ulaw
allow=alaw
allow=g729
cancalllforward=no
canreinvite=no
ipaddr=192.168.1.200
port=5060
context=from_carrier

[carrier-2]
type=peer
host=192.168.1.200
dtmfmode=rfc2833
insecure=invite
disallow=all
allow=g729:6060
cancalllforward=no
canreinvite=no
ipaddr=192.168.1.200
port=5060

If a call arrives from carrier-1, we would like to be able to respond with any codec that we support, namely ulaw, alaw, g729, (by the way, we really appreciate the feature introduced on 1.8, "preferred_codec_only" on sip.conf that allows to reply only with 1 codec of the group, that avoids the uncertainty of knowing what codec was used if the calling party does not re-INVITE with 1 codec only to define the codec to use, because the reply has all the supported codecs).

And if we receive a call from other carriers and need to send it out using the same "carrier-1" but with 1 specific codec/ptime then we do Dial(SIP/carrier-2/${EXTEN}) to be able to send the INVITE only with that one codec and chosen ptime.

We thought that the process of matching the carrier was something like this: (simplified of course)

1- a call came, find if there is any sip device defined as user or friend (never look for a peer since they are for outbound calls only)
2- once found, then get the context
3- then look for an extension on that context in the dialplan that matches the dialed number

For outbound calls, since with Dial one has to specify the name of the sip device after the channel it is just a matter of finding a sip device defined as peer (not user or friend) with that name i.e:, Dial(SIP/carrier-2/${EXTEN}). Then once found, use the codecs and other parameters like dtmmode to create the outbound call etc.

I was told to use the variables SIP_CODEC_OUTBOUND and SIP_CODEC_INBOUND as a workaround and that makes a lot of sense. But although they go a long way on achieving our setup we found that we can not set the ptime when using the variable on the dialplan.

For example, having 1 carrier like this allows me to reply with any codec on that list if the call comes on that trunk, but if I need to send a call with g729:60 using that carrier on an outbound call I can not do this
exten => 1234.,n,SET(SIP_CODEC_OUTBOUND=g729:60) because asterisk complains about it and the console logs say "codec not found" or something similar (note that codec g729 was defined with default ptime in sip.conf)

[carrier-1]
type=friend; or peer
host=192.168.1.200
dtmfmode=rfc2833
insecure=invite
disallow=all
allow=ulaw
allow=alaw
allow=g729
cancalllforward=no
canreinvite=no
ipaddr=192.168.1.200
port=5060
context=from_carrier

Is there any way to configure it once and be able to have total control of the calls in and out this carrier?
Why was it working on previous versions?
I compared the code of the function "find_peer" on 1.6.0.3-rc1 and 1.8.3/1.8.5 and the difference is huge.

I definitely like the use of the variables on the dialplan and I agree with having the carrier defined only once but I find that it is kind of limiting on what you can do now on that regard. Maybe the idea is adding more variables to enhance the control on the dialplan. Anyways I would like to have a definitive and assertive  answer to this behavior. And of course I would appreciate any ideas that would help us achieve the same setup.
thanks a lot in advance

Fabian

Comments:By: Fabian Borot (fborot) 2011-09-02 16:38:36.564-0500

This is the NOTICE that we see on the console when the dialplan reaches this priority: exten => 7862222222,n,SET(_SIP_CODEC_OUTBOUND=g729:60)

[Sep  2 16:20:28] NOTICE[1556]: chan_sip.c:6281 try_suggested_sip_codec: Ignoring ${SIP_CODEC} variable because of unrecognized/not configured codec (check allow/disallow in sip.conf): g729:60

When we do not specify the ptime with the variable on the dialplan we see this NOTICE, which means that the codec specified was accepted:
[Sep  2 16:22:37] NOTICE[1562]: chan_sip.c:6274 try_suggested_sip_codec: Changing codec to 'g729' for this call because of ${SIP_CODEC} variable

Also, I notice that for the inbound variable it is fine to use these 2 formats: "_SIP_CODEC_INBOUND" and "SIP_CODEC_INBOUND". But for the outbound it has to be "_SIP_CODEC_OUTBOUND", w/o the "_" at the very beginning it does not work.

Also, if in the sip.conf you have codec=ulaw:60 and in the dialplan you use SET(_SIP_CODEC_OUTBOUND=g729) w/o specifying the ptime the INVITE uses the codec as defined on the sip.conf and sends g729:60 which is the intended behaviour we need for the outbound trunk.
But at teh same time this is the part that is preventing us to use this approach, because I thought maybe I can setup the codecs on the sip.conf with the ptime and for the outbound use SET(_SIP_CODEC_OUTBOUND=g729) and the INVITE is sent with ptime 60 (which is what we want) but then it means that if for inbound I chose g729 it will be used as g729:60, because it takes precedence and on the dialplan you have no control of the ptime feature. That might not be desired because the inbound trunk may not support g729:60.

I also want to clarify something at this point, one can logically think: "Wait a minute, why wouldn't the inbound trunk support g729:60 if it is the same carrier that on the outbound supports it fine?" The reason is because some softswitches can not do transcoding but passthrough (early versions of nextone, current nextone w/o transcoding modules, entice softswitch etc).

By: Leif Madsen (lmadsen) 2011-09-07 10:04:51.865-0500

Well, as far as I'm aware, a type=user has always matched on the From header, and the type=peer matches on the IP address. All the documentation from 1.4 and forward has pretty much always described it in that fashion.

Defining a host= setting for a type=user doesn't make any sense, since that type doesn't match on IP addresses.

If what you're describing was working on 1.6.0.3, then that was a bug that has since been 'fixed'.
By: Leif Madsen (lmadsen) 2011-09-07 10:06:07.080-0500

I think you should use the asterisk-users mailing list to help determine how to do the control you want, because changing the way matching is performed in chan_sip.c is not going to get changed as that would affect too many people.
By: Fabian Borot (fborot) 2011-09-07 12:20:50.780-0500

Dear Leif, thank you a lot for providing us with the definitive answer; that is what we were looking for. You are right when you say that the doc has been describing it like that since version 1.4, but since it was working for us in the way that we described it I guess that we got used to it.