In the dialplan I answer the call and then call the mod_java script. I log the UUID to the console. It looks valid. How do I verify that the UUID is valid and the correct UUID? On Fri, Apr 4, 2008 at 6:27 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:

The change was to the underlying C++ constructor to keep track of if the wrapper actually has control of a session or not.

CoreSession::CoreSession(char *nuuid) {

if (session = switch_core_session_locate(nuuid)) { channel = switch_core_session_get_channel(session); init_vars(); uuid = strdup(nuuid); memset(&caller_profile, 0, sizeof(caller_profile)); allocated = 1; } }

all the methods contain a sanity check that says. if (!(session && allocated)) { switch_log_printf(SWITCH_CHANNEL_LOG,SWITCH_LOG_ERROR, "session is not initalized\n"); return x;

so make sure that the uuid string is actually the uuid of your call. perhaps the author of this module could look at creating the session wrapper for you when it's in the context of a call like the js mod does.

On Fri, Apr 4, 2008 at 7:54 AM, Damjan Jovanovic <damjan@ecntelecoms.com> wrote:

...

X-ECN Telecoms-MailScanner-Information: Contact ECN Telecoms X-ECN Telecoms-MailScanner: Found to be clean X-ECN Telecoms-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-102.277, required 6, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.48, USER_IN_WHITELIST -100.00) X-ECN Telecoms-MailScanner-From: damjan@ecntelecoms.com X-Spam-Status: No

On Fri, 2008-04-04 at 00:38 -0700, jonathan augenstine wrote:

...

I have a mod-java script that is encountering an error on the latest version from svn.

The script runs successfully on build: FreeSwitch Version 1.0.pre3 (7616M)

When I retrieve the latest version from svn (8019) I get the following output from the console:

2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is not initalized 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is not initalized 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:153 execute() session is not initalized 2008-04-04 02:03:15 [DEBUG] switch_cpp.cpp:98 ~CoreSession() CoreSession::~CoreSession desctructor

Make sure the UUID is valid.

Otherwise, whoever changed the semantics of the session API should also patch mod_java.

...

Java code that works on 7616 but fails on 8019:

public void run(String sessionUuid, String args) { freeswitch.console_log("notice", "INBOUND UUID: " + sessionUuid + " ARGS: " + args + "\n"); JavaSession session = null;

try { session = new JavaSession(sessionUuid);

session.setAutoHangup(false);

String raw_dnis = session.getVariable("originate_caller_id_number"); String raw_ani = session.getVariable("caller_id_number");

Has something changed on the Java module. Do I need any new additional initialization?

Jonathan

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Bye Damjan

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/

AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

I fixed this issue in tree in latest trunk damjan I have a few suggestions for you: 1) in the scripts you have to say...... session = new JavaSession(sessionUuid); maybe you can do this automatically when the script is invoked as an application. 2) you should add an api interface like spidermonkey and python have caled "java_run" then you could use the cli, xml-rpc and the event_socket to invoke standalone scripts in their own thread. 3) The DTMF / event stuff is not fully exposed. When you set an event callback you can get an event or a DTMF obj When you get a DTMF the obj supplies duration as well as the digit that was dialed. When you get an event it's a structure similar to an email, jabber message etc with a type, headers and a body. so you should build a class around the switch_event_t. That way, you can parse, create and fire events. maybe we will make a c++ wrapper for that too so swig will do it for us. On Fri, Apr 4, 2008 at 12:26 PM, jonathan augenstine <jaugenstine@gmail.com> wrote:

Damjan,

What I am trying to do is to implement a script that plays a prompt and collects digits. I am able to use streamFile and getDigits to accomplish this task but it produces an unacceptable experience, in that if experienced people use the system they want to start entering digits before the prompt completes and streamFile/getDigits will not support this behavior. I have tried using playAndGetDigits but that method crashes freeswitch on the older version. When I tried updating freeswitch I encountered the error noted below. If you can give me some guidance I will help trouble shoot the initialization problem. Thank you.

Jonathan

On Fri, Apr 4, 2008 at 5:54 AM, Damjan Jovanovic <damjan@ecntelecoms.com> wrote:

...

X-ECN Telecoms-MailScanner-Information: Contact ECN Telecoms X-ECN Telecoms-MailScanner: Found to be clean X-ECN Telecoms-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-102.277, required 6, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.48, USER_IN_WHITELIST -100.00) X-ECN Telecoms-MailScanner-From: damjan@ecntelecoms.com X-Spam-Status: No

On Fri, 2008-04-04 at 00:38 -0700, jonathan augenstine wrote:

...

I have a mod-java script that is encountering an error on the latest version from svn.

The script runs successfully on build: FreeSwitch Version 1.0.pre3 (7616M)

When I retrieve the latest version from svn (8019) I get the following output from the console:

2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is not initalized 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is not initalized 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:153 execute() session is not initalized 2008-04-04 02:03:15 [DEBUG] switch_cpp.cpp:98 ~CoreSession() CoreSession::~CoreSession desctructor

Make sure the UUID is valid.

Otherwise, whoever changed the semantics of the session API should also patch mod_java.

...

Java code that works on 7616 but fails on 8019:

public void run(String sessionUuid, String args) { freeswitch.console_log("notice", "INBOUND UUID: " + sessionUuid + " ARGS: " + args + "\n"); JavaSession session = null;

try { session = new JavaSession(sessionUuid);

session.setAutoHangup(false);

String raw_dnis = session.getVariable("originate_caller_id_number"); String raw_ani = session.getVariable("caller_id_number");

Has something changed on the Java module. Do I need any new additional initialization?

Jonathan

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Bye Damjan

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

X-ECN Telecoms-MailScanner-Information: Contact ECN Telecoms X-ECN Telecoms-MailScanner: Found to be clean X-ECN Telecoms-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-103.715, required 6, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.68, BAYES_00 -2.60, USER_IN_WHITELIST -100.00) X-ECN Telecoms-MailScanner-From: damjan@ecntelecoms.com X-Spam-Status: No On Fri, 2008-04-04 at 18:08 -0500, Anthony Minessale wrote:

I fixed this issue in tree in latest trunk

damjan I have a few suggestions for you:

1) in the scripts you have to say......

session = new JavaSession(sessionUuid);

maybe you can do this automatically when the script is invoked as an application.

Maybe.

2) you should add an api interface like spidermonkey and python have caled "java_run" then you could use the cli, xml-rpc and the event_socket to invoke standalone scripts in their own thread.

'Scripts' are for scripting languages...

3) The DTMF / event stuff is not fully exposed.

Yes I'll try to get that done too.

When you set an event callback you can get an event or a DTMF obj

When you get a DTMF the obj supplies duration as well as the digit that was dialed. When you get an event it's a structure similar to an email, jabber message etc with a type, headers and a body.

so you should build a class around the switch_event_t.

That way, you can parse, create and fire events.

maybe we will make a c++ wrapper for that too so swig will do it for us.

I'm thinking of ditching swig. I don't know what it's like for other languages, but for Java it's a disaster. I spent most of the time writing mod_java just coercing swig to get it to generate working code, and the Java -> Freeswitch interface still looks very foreign. The application interface that runs an interpret for a given script doesn't really work for languages like Java anyway. The current implementation loads classes from disk on every call, and since each class is loaded with a different classloader, classes won't share their static data between invocations. I prefer what mod_mono did, that is, a way to write native freeswitch modules in Java. That would also provide a nice way to control object lifetimes, which mod_java currently doesn't have. Regards Damjan

On Fri, Apr 4, 2008 at 12:26 PM, jonathan augenstine <jaugenstine@gmail.com> wrote: Damjan,

What I am trying to do is to implement a script that plays a prompt and collects digits. I am able to use streamFile and getDigits to accomplish this task but it produces an unacceptable experience, in that if experienced people use the system they want to start entering digits before the prompt completes and streamFile/getDigits will not support this behavior. I have tried using playAndGetDigits but that method crashes freeswitch on the older version. When I tried updating freeswitch I encountered the error noted below. If you can give me some guidance I will help trouble shoot the initialization problem. Thank you.

Jonathan

On Fri, Apr 4, 2008 at 5:54 AM, Damjan Jovanovic <damjan@ecntelecoms.com> wrote:

X-ECN Telecoms-MailScanner-Information: Contact ECN Telecoms X-ECN Telecoms-MailScanner: Found to be clean X-ECN Telecoms-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-102.277, required 6, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.48, USER_IN_WHITELIST -100.00) X-ECN Telecoms-MailScanner-From: damjan@ecntelecoms.com X-Spam-Status: No

On Fri, 2008-04-04 at 00:38 -0700, jonathan augenstine wrote: > I have a mod-java script that is encountering an error on the latest > version from svn. > > The script runs successfully on build: FreeSwitch Version 1.0.pre3 > (7616M) > > When I retrieve the latest version from svn (8019) I get the following > output from the console: > > 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is > not initalized > 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:146 getVariable() session is > not initalized > 2008-04-04 02:03:15 [ERR] switch_cpp.cpp:153 execute() session is not > initalized > 2008-04-04 02:03:15 [DEBUG] switch_cpp.cpp:98 ~CoreSession() > CoreSession::~CoreSession desctructor

Make sure the UUID is valid.

Otherwise, whoever changed the semantics of the session API should also patch mod_java.

> Java code that works on 7616 but fails on 8019: > > public void run(String sessionUuid, String args) > { > freeswitch.console_log("notice", "INBOUND UUID: " + > sessionUuid + " ARGS: " + args + "\n"); > JavaSession session = null; > > try > { > session = new JavaSession(sessionUuid); > > session.setAutoHangup(false); > > String raw_dnis = > session.getVariable("originate_caller_id_number"); > String raw_ani = session.getVariable("caller_id_number"); > > Has something changed on the Java module. Do I need any new > additional initialization? > > Jonathan >

> _______________________________________________ > Freeswitch-dev mailing list > Freeswitch-dev@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org

Bye Damjan

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/

AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Hi all at third today :-) I'm trying to make call-forward (on all failures, but it is not relevant, I think) but don't know how... I used "transfer" application but it didn't work like i expected. The scenario was as follows: Really simple dialplan <extension name="Eeee"> <condition field="destination_number" expression="^(23)$"> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> <action application="transfer" data="22"/> </condition> </extension> And than user 21 calls number 23 which is not registered. Call succesfully rings on user 22 but: 1. There is no "181 Call is being forwarded" sent. 2. INVITE to user 22 lacks "Diversion" header. If someone interested I have full pcap dump. Could someone point me to right solution how to properly implement call forwarding? I mean 181 send back, and INVITE with Diversion header with proper forwarding reason and forward counter. When I looked at Channel_Variables I didn't find anything suitable... Any suggestion is really appreciated :-) Best regards, kokoska.rokoska

You can also try this: <extension name="Eeee"> <condition field="destination_number" expression="^(23)$"> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> <action application="respond" data="181 Call is being forwarded"/> <action application="export" data="sip_h_Diversion=23@$$ {domain};reason=unavailable"/> <!-- Since we are a B2BUA this just sends the call back into the dialplan which would be the same as bridge sofia/default/22%$${domain} --> <action application="transfer" data="22"/> </condition> </extension> /b On Apr 6, 2008, at 4:03 PM, Anthony Minessale wrote:

The transfer app sends the same call to some other extension at some other dialplan within the switch. We are not a sip specific switch so we have to abstract many concepts.

If you are trying to redirect the call we have 2 ways the redirect application

<action application="redirect" data="sip:user@host"/> This will result in a 302 redirect in the case of a sip channel

<action application="deflect" data="sip:user@host"/> This will result in a REFER to the specified uri

That is the only 2 ways we support, if you are looking to divert like a proxy does remember we are only a b2bua and do not perform proxy features, see openser for that.

On Sun, Apr 6, 2008 at 2:13 PM, kokoska rokoska <kokoska.rokoska@post.cz

...

wrote:

Hi all at third today :-)

I'm trying to make call-forward (on all failures, but it is not relevant, I think) but don't know how... I used "transfer" application but it didn't work like i expected.

The scenario was as follows:

Really simple dialplan <extension name="Eeee"> <condition field="destination_number" expression="^(23)$"> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> <action application="transfer" data="22"/> </condition> </extension>

And than user 21 calls number 23 which is not registered. Call succesfully rings on user 22 but: 1. There is no "181 Call is being forwarded" sent. 2. INVITE to user 22 lacks "Diversion" header. If someone interested I have full pcap dump.

Could someone point me to right solution how to properly implement call forwarding? I mean 181 send back, and INVITE with Diversion header with proper forwarding reason and forward counter. When I looked at Channel_Variables I didn't find anything suitable...

Any suggestion is really appreciated :-)

Best regards,

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/

AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

On Apr 6, 2008, at 5:33 PM, kokoska rokoska wrote:

Thank you very much, Brian, for super tip!

I know I can append headers (yout wrote it to me few days ago :-), but I didn't know how to modify replies. And if config above will work, it is exactly what I need.

BTW: Is there a way how to get contents of SIP headers on incoming INVITEs? (I'm wondering especially on standard "Diversion" header - parameters "reason" and "counter" - and nonstandard but widely used "X-HopCounter" header.) Do you have any hints here?

Isn't this what Max-Forwards header is for? Inbound Diversion is sip_h_diversion variable. We already kill the call if the Max-Forwards makes it to zero. /b

Thanks once more, regards

kokoska.rokoska

On Apr 7, 2008, at 3:45 AM, kokoska rokoska wrote:

...

We already kill the call if the Max-Forwards makes it to zero.

No, unfotunately, Max-Forwards is not for the same thing. X-HopCounter we (I and lot of VoIP providers around me) use for overall "hops" (visited call-routers) counting - ISUP and SIP. This variable comes from SS7 world (ISUP) and is mandatory for good interconnection (helps against loops etc. - similary as MaxForwards does) especialy if RNPDB comes into the game :-) First router sets HopCounter to 31, every next router should decrement the value on every single processing attempt (i.e. if call goes thru 5 extensions in Freeswitch dialplan it should be decremented by 5) and on 0 or lower values router should stop routing and reject the call...

I think we would probably convert this to a Max-Forwards when doing a sip interconnect, I need to see if we decrement it in a transfer within the switch, I believe we already do. But like all the other headers, we can get it with variables, and create the other header, but we only auto decrement the Max-Forwards. That being said, it is not required that we start Max-Forwards at 70. I have in the past passed this along from ss7 by either passing the value directly from ss7 or using a ratio calculation similar to how cisco does it. Mike

Brian West napsal(a):

You can also try this:

<extension name="Eeee"> <condition field="destination_number" expression="^(23)$"> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> <action application="respond" data="181 Call is being forwarded"/> <action application="export" data="sip_h_Diversion=23@$$ {domain};reason=unavailable"/> <!-- Since we are a B2BUA this just sends the call back into the dialplan which would be the same as bridge sofia/default/22%$${domain} --> <action application="transfer" data="22"/> </condition> </extension>

Your config works exactly as I need. Thank you Brian! I have two more questions about SIP headers, replies etc. 1. Is there a way how to add headers to replies? If I simply try to prepend "respond" app with "export" of desired SIP header, it doesn't work - the header is added to the INVITE, not to 181... 2. Is there a way how to modify SIP headers or - may be - remove headers? Thanks a lot once more, regards kokoska.rokoska

Michael Jerris napsal(a):

On Apr 7, 2008, at 6:08 AM, kokoska rokoska wrote:

...

our config works exactly as I need. Thank you Brian! I have two more questions about SIP headers, replies etc.

1. Is there a way how to add headers to replies? If I simply try to prepend "respond" app with "export" of desired SIP header, it doesn't work - the header is added to the INVITE, not to 181...

Not without adding new code.

OK.

...

2. Is there a way how to modify SIP headers or - may be - remove headers?

Modify, it depends, which ones are you trying to modify? Remove, unlikely without new code, again, we are happy to take a look at patches to add functionality like this.

Mike

It was just a question :-) For now I can't figure out any real world example... About new code, patches: Like I wrote before, I'm not a programmer. But when I be more familiar with Freeswitch I try to help to add some useful code :-) Thank you very much, Michael, for your answer! Regards, kokoska.rokoska

See brian's example on the list for something that might handle your situation. I'm not trying to explain away the need for what you want I just want to make sure you understand how we have things designed. You may want to join our irc channel for more realtime interaction. #freeswitch on irc.freenode.net On Sun, Apr 6, 2008 at 5:23 PM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:

Thank you, Anthony, for your answer. I will write my comments in the e-mail body.

Anthony Minessale napsal(a):

...

The transfer app sends the same call to some other extension at some other dialplan within the switch. We are not a sip specific switch so we have to abstract many concepts.

Yes, I know it. But I just ask :-) BTW: Very similar messaging concept is IMO used not only in SIP but in ISUP (and thus in real telephony world) too.

...

If you are trying to redirect the call we have 2 ways the redirect application

<action application="redirect" data="sip:user@host"/> This will result in a 302 redirect in the case of a sip channel

I saw this app. But I want to forward the call, not redirect.

...

<action application="deflect" data="sip:user@host"/> This will result in a REFER to the specified uri

REFER is IMO used for replacing of one leg of call with another one (RFC3515), i.e. for "transfer".

...

That is the only 2 ways we support, if you are looking to divert like a proxy does

Yes, this is what I have to do, because I need to be "transparent" for calls come from PSTN and than go back to PSTN too (ISUP->SIP->ISUP).

...

remember we are only a b2bua and do not perform proxy features,

OK. This is big advantage for me, because I need B2BUA :-) But what I want is possible with B2BUA. Even with Asterisk, but only with very ugly hacks I hope I am avoid with Freeswitch.

...

see openser for that.

I'm intensive user of OpenSER. In my current setup it is used as loadbalancer, registrar, presence server etc. But I realy need B2BUA and ability to manipulate with media (with much more sophisticated way than SEMS does).

Thanks again for your replay, regards

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

Anthony Minessale wrote:

all X-headers are made into variables for you route the call to the "info" app to see a dump of all the variables for that call.

Thank you very much, Anthony, for this info! Am I right if I think that in the "info" app I see all important SIP headers "converted" to variables?

If there is some other standard header that we do not already supply that you would like to see as a variable let us know and we can consider it.

If I find this kind of header, I tell you :-) BTW: In INVITEs from Freeswitch I saw Remote-Party-Id header. Isn't be better to include P-Asserted-Identity instead? Or, even better, make this configurable? Many thanks, regards kokoska.rokoska

yes you should create them by yourself. We cannot guarantee the syntax to create indexes for each type of db. We do make an effort to auto-create the table for you but if you are serious about it you may choose to set the db up yourself. On Sun, Apr 6, 2008 at 9:32 AM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:

Hi all again,

I have just setted up ODBC connection to my MySQL DB and after it I look at tables created by Freeswitch and I see: There are no indexes.

I'm not big DB guy, but I think that with even few thousands of rows (i.e. users) it will be much faster to do DB lookup based on indexes rather than on table fullscans.

Am I missing something, or should I create indexes by myself? If yes, on what columns? Any comments are really welcome :-)

Regards,

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

Wasim Baig napsal(a):

On Sun, Apr 6, 2008 at 9:32 AM, kokoska rokoska <kokoska.rokoska@post.cz <mailto:kokoska.rokoska@post.cz>> wrote:

Am I missing something, or should I create indexes by myself? If yes, on what columns?

that really all depends on what sort of queries you'll be running ... here is a sample schema i use at one place

CREATE TABLE `cdr` ( `accountcode` varchar(20) NOT NULL default '', `caller_id_number` varchar(80) NOT NULL default '', `destination_number` varchar(80) NOT NULL default '', `context` varchar(80) NOT NULL default '', `caller_id` varchar(80) NOT NULL default '', `channel_name` varchar(80) NOT NULL default '', `bridge_channel` varchar(80) NOT NULL default '', `last_app` varchar(80) NOT NULL default '', `last_arg` varchar(80) NOT NULL default '', `start_timestamp` datetime NOT NULL default '0000-00-00 00:00:00', `answer_timestamp` datetime NOT NULL default '0000-00-00 00:00:00', `end_timestamp` datetime NOT NULL default '0000-00-00 00:00:00', `duration` int(11) NOT NULL default '0', `billsec` int(11) NOT NULL default '0', `hangup_cause` varchar(45) NOT NULL default '', `amaflags` varchar(45) NOT NULL default '', `uuid` varchar(36) NOT NULL default '', `userfield` varchar(20) NOT NULL default '', `cost` varchar(20) default NULL, KEY `userfield` (`userfield`), KEY `accountcode` (`accountcode`), KEY `hangup_cause` (`hangup_cause`), KEY `context` (`context`), KEY `destination_number` (`destination_number`), KEY `end_timestamp` (`end_timestamp`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

-- wasim h. baig | principal consultant | convergence pk | +92 300 8508070

Thank you very much, Wasim, for your answer! I ask on indexes on tables used by Freeswitch for registrations, voicemail etc. The CDR table isn't be much trouble for me I hope, because I know exactly what kind of lookups i will do on it :-) But your SQL query is very good hint for me. Best regards, kokoska.rokoska

We do not have in-depth documentation on the sql statements but the way they are used for registration id more or less selecting the contact based on either the callid or the to and from fields, the same with the subscriptions. The other presence stuff is a little more involved but we do not have a detailed description. On Sun, Apr 6, 2008 at 5:10 PM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:

Anthony Minessale napsal(a):

...

yes you should create them by yourself. We cannot guarantee the syntax to create indexes for each type of db. We do make an effort to auto-create the table for you but if you are serious about it you may choose to set the db up yourself.

Thank you very much, Anthony, for your response!

I will do it, but I'd like to know if somewhere exists documentation/description of DB queries Freeswitch do. Or should I "extract" this kind of info from source codes only?

Regards,

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

Please re-test this with current trunk. A patch just went in to address this issue. Mike On Apr 6, 2008, at 4:48 AM, kokoska rokoska wrote:

Hi all,

I just start to play with Freeswitch and first thing I discover is bad REGISTER processing in mod_sofia :-(

The problem is, that Sofia modifies Contact header (append port 5060 which is not in original REGISTER request) in 200 OK reply and thus a ot of clients refuses it (for example SJPhone, Nokia E series etc.). Full debug is included at the end of my e-mail.

In this manner Freeswitch behaviour IMO violates rfc3261:

19.1.4 URI Comparison ...

A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components.

Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. ...

Could you please tell me how to configure mod_sofia to properly handle REGISTER request?

Thanx a lot, regards

kokoska.rokoska

---------------------------- SIP debug made with SJPhone:

2008-04-06 08:26:36.093 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001e47f8893c000053f900000006;rport From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065> Contact: <sip:1000@192.168.1.101> Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 3 REGISTER Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0

2008-04-06 08:26:36.109 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001e47f8893c000053f900000006;rport=5060 From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065>;tag=vHv1X7K9yemUe Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 3 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128", nonce="3a4ee704-f9a9-4789-9853-e8e8d6b562e9", algorithm=MD5, qop="auth" Content-Length: 0

2008-04-06 08:26:36.109 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001f47f8893c00007cb100000008;rport From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065> Contact: <sip:1000@192.168.1.101> Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 4 REGISTER Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0 Authorization: Digest username="1000",realm="192.168.1.128",nonce="3a4ee704-f9a9-4789-9853- e8e8d6b562e9",uri="sip: 192.168.1.128 : 5065 ",response = "cd1a36378bdb3efaabcfa263a6b9f24c ",algorithm=MD5,cnonce="5536ed3a7",qop=auth,nc=00000001

2008-04-06 08:26:36.109 UDP 192.168.1.128:5065->LOCAL SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001f47f8893c00007cb100000008;rport=5060 From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065>;tag=XtNtZ24cvQaea Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 4 REGISTER Contact: "user" <sip:1000@192.168.1.101:5060>;expires=60 User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer Content-Length: 0

10:26:36 SIP.Registration WARNING Registrar did not registered none of our contacts! 10:26:36 SIP.Registration NOTICE Foreign contacts returned by the server: sip:1000@192.168.1.101:5060 10:26:36 SIP.Registration INFO Not registered sip:1000@192.168.1.128:5065 10:26:36 SIP.RegistrationClient INFO Registration reattempt scheduled after 60 seconds 10:26:36 SIP.Network DEBUG 2008-04-06 08:26:36.234 UDP 192.168.1.128:5065->LOCAL NOTIFY sip:1000@192.168.1.101:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.128:5065;rport;branch=z9hG4bKc5ZBa6F96yHee Max-Forwards: 70 From: <sip:1000@192.168.1.128>;tag=y3eK1XNgS000N To: <sip:1000@192.168.1.128> Call-ID: feef82f8-7e55-122b-fb8d-000854d1424f CSeq: 97616858 NOTIFY Contact: <sip:mod_sofia@192.168.1.128:5065> User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer Event: message-summary Subscription-State: terminated;timeout Content-Type: application/simple-message-summary Content-Length: 65

Messages-Waiting: no Message-Account: sip:1000@192.168.1.128

10:26:36 SIP.Network DEBUG 2008-04-06 08:26:36.234 UDP LOCAL->192.168.1.128:5065 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.128 :5065;branch=z9hG4bKc5ZBa6F96yHee;rport=5065;received=192.168.1.128 From: <sip:1000@192.168.1.128>;tag=y3eK1XNgS000N To: "unknown" <sip:1000@192.168.1.128>;tag=6c19ed424 Call-ID: feef82f8-7e55-122b-fb8d-000854d1424f CSeq: 97616858 NOTIFY Content-Length: 0 Server: SJphone/1.65.377a (SJ Labs)

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Michael Jerris napsal(a):

Please re-test this with current trunk. A patch just went in to address this issue.

Mike

Hi Michael, I'm afraid I find another trouble in REGISTER handling: From time to time FreeSWITCH responds to the first REGISTER with 401 including some nonce and to the second REGISTER responds with 401 too, but with another nonce. I'm not sure if it conforms to RFCs or not, but some UAC stops sending another REGISTER. And, even thou, I thing it is not good practice to change nonce between two consequential requests. Could you, please, tell me if it is a bug (and at what side) or feature? :-) Thank you. Best regards, kokoska.rokoska ---------------------- 2008-04-08 14:31:13.390 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034947fb81b10000690e0000027b;rport From: "unknown" <sip:0002*23@192.168.1.128:5065>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065> Contact: <sip:0002*23@192.168.1.101>;expires=150 Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 257 REGISTER Expires: 150 Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0 2008-04-08 14:31:13.390 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034947fb81b10000690e0000027b;rport=5060 From: "unknown" <sip:0002*23@192.168.1.128:5065>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065>;tag=mF1e5j94t93BD Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 257 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8045 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128", nonce="51065d76-34b9-49cc-ba37-74cf3975b420", algorithm=MD5, qop="auth" Content-Length: 0 2008-04-08 14:31:13.390 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034a47fb81b1000011ce0000027d;rport From: "unknown" <sip:0002*23@192.168.1.128:5065>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065> Contact: <sip:0002*23@192.168.1.101>;expires=150 Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 258 REGISTER Expires: 150 Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0 Authorization: Digest username="0002*23",realm="192.168.1.128",nonce="51065d76-34b9-49cc-ba37-74cf3975b420",uri="sip:192.168.1.128:5065",response="6c07a79b8cd54c9092f65e01637ba90a",algorithm=MD5,cnonce="1b791b80090",qop=auth,nc=00000001 2008-04-08 14:31:13.406 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034a47fb81b1000011ce0000027d;rport=5060 From: "unknown" <sip:0002*23@192.168.1.128:5065>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065>;tag=Nrt76Dt8Qjtyr Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 258 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8045 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128", nonce="dfddd004-d0df-4a8c-9686-b76d12f5f42b", stale="true", algorithm=MD5, qop="auth" Content-Length: 0

I have inspected logs from five different clients (X-Lite, SJPhone, Linksys SPA PAP2, Linksys SPA 2100, FritzBox 7170) for last 24 hours or so, and issue I reported never happens. So I thing it is fixed :-) Thank you very much, Anthony! Best regrads, kokoska.rokoska Anthony Minessale napsal(a):

can you try lastest trunk and see if that's better?

On Tue, Apr 8, 2008 at 10:03 AM, kokoska rokoska <kokoska.rokoska@post.cz <mailto:kokoska.rokoska@post.cz>> wrote:

Michael Jerris napsal(a): > Please re-test this with current trunk. A patch just went in to > address this issue. > > Mike >

Hi Michael,

I'm afraid I find another trouble in REGISTER handling: From time to time FreeSWITCH responds to the first REGISTER with 401 including some nonce and to the second REGISTER responds with 401 too, but with another nonce.

I'm not sure if it conforms to RFCs or not, but some UAC stops sending another REGISTER. And, even thou, I thing it is not good practice to change nonce between two consequential requests.

Could you, please, tell me if it is a bug (and at what side) or feature? :-) Thank you.

Best regards,

kokoska.rokoska

----------------------

2008-04-08 14:31:13.390 UDP LOCAL->192.168.1.128:5065 <http://192.168.1.128:5065> REGISTER sip:192.168.1.128:5065 <http://192.168.1.128:5065> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034947fb81b10000690e0000027b;rport From: "unknown" <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>> Contact: <sip:0002*23@192.168.1.101 <mailto:23@192.168.1.101>>;expires=150 Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 257 REGISTER Expires: 150 Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0

2008-04-08 14:31:13.390 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034947fb81b10000690e0000027b;rport=5060 From: "unknown" <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=mF1e5j94t93BD Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 257 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8045 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128 <http://192.168.1.128>", nonce="51065d76-34b9-49cc-ba37-74cf3975b420", algorithm=MD5, qop="auth" Content-Length: 0

2008-04-08 14:31:13.390 UDP LOCAL->192.168.1.128:5065 <http://192.168.1.128:5065> REGISTER sip:192.168.1.128:5065 <http://192.168.1.128:5065> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034a47fb81b1000011ce0000027d;rport From: "unknown" <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>> Contact: <sip:0002*23@192.168.1.101 <mailto:23@192.168.1.101>>;expires=150 Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 258 REGISTER Expires: 150 Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0 Authorization: Digest username="0002*23",realm="192.168.1.128 <http://192.168.1.128>",nonce="51065d76-34b9-49cc-ba37-74cf3975b420",uri="sip:192.168.1.128:5065 <http://192.168.1.128:5065>",response="6c07a79b8cd54c9092f65e01637ba90a",algorithm=MD5,cnonce="1b791b80090",qop=auth,nc=00000001

2008-04-08 14:31:13.406 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bKc0a801650000034a47fb81b1000011ce0000027d;rport=5060 From: "unknown" <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=2afd1b80090 To: <sip:0002*23@192.168.1.128:5065 <http://23@192.168.1.128:5065>>;tag=Nrt76Dt8Qjtyr Call-ID: 456C47312F944D908DF93F42CD6D7F2A0xc0a80165 CSeq: 258 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8045 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128 <http://192.168.1.128>", nonce="dfddd004-d0df-4a8c-9686-b76d12f5f42b", stale="true", algorithm=MD5, qop="auth" Content-Length: 0

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org <mailto:Freeswitch-dev@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/

AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

------------------------------------------------------------------------

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

yes do you have both a pcap and a console trace of the call. start freeswitch with TPORT_LOG=1 TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch set debug level

console loglevel debug

capture all the text on the console my guess without seeing it is that user 22 is behind nat or a proxy or something and you do not have keepalive turned on so the path for the phone on 22 to send the bye to FS is gone so FS is not getting the bye from phone 22 We would never say 481 because if FS thinks the call leg should still be up it will last until the call is terminated one way or another. Remember, each leg of the bridged call is a separate sip call as we are a b2bua. On Tue, Apr 8, 2008 at 10:25 AM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:

Hi all,

I'm afraid I bug in FreeSWITCH SIP call handling. The scenario is as follows:

Very simple dialplan:

<extension name="E1"> <condition field="destination_number" expression="^(23)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> <action application="respond" data="181 Call is being forwarded"/> <action application="export" data="sip_h_Diversion=23@$$ {domain};reason=unavailable"/> <action application="transfer" data="22"/> </condition> </extension> <extension name="E2"> <condition field="destination_number" expression="^(22)$"> <action application="set" data="hangup_after_bridge=true"/> <action application="bridge" data="sofia/default/$1%$${domain}"/> </condition> </extension>

User status:

Users 21 and 22 are registered, user 22 not.

Call flow:

User 21 calls number 23, recieves back 181 and phone 22 starts ringing (Diversion header is properly appended). Than user 22 answers (sends 200 OK and recives ACK) and after short conversation hangs up. And user 21's call leg isn't hanged up by Freeswitch (BYE is not sent). After few seconds user 21 hangs up manualy and recieves 200 OK instead of 481 Call Leg/Transaction Does Not Exist...

Is it a bug or am I doing something wrong?

Best regards,

kokoska.rokoska

PS: If someone interested I have pcap dump of communication.

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

Anthony Minessale napsal(a):

yes do you have both a pcap and a console trace of the call.

start freeswitch with TPORT_LOG=1

TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch

set debug level

...

console loglevel debug

capture all the text on the console

I have just updated to current trunk and after a while I do the test and capture all possible dumps

my guess without seeing it is that user 22 is behind nat or a proxy or something and you do not have keepalive turned on so the path for the phone on 22 to send the bye to FS is gone so FS is not getting the bye from phone 22

No, no. There is nothing (except ethernet switch :-) between Freeswitch and UACs. They are all on the same lan subnet.

We would never say 481 because if FS thinks the call leg should still be up it will last until the call is terminated one way or another.

But if one leg of call was hanged up (and "hangup after bridge" is set) I mean Freeswitch has to hang up second leg and than drop transaction.

Remember, each leg of the bridged call is a separate sip call as we are a b2bua.

Yes, I remember it :-) But it IMO have nothing to do with 481. Every UAC or UAS has to be able to send 481 if transaction (call leg) doesn't exists. And from my oppinion most of UAs do it well (better to say, I have never heard about one didn't do it). It is mandatory by RFC3261, 21.4.19 and even Asterisk does it :-) Thank you, Antohny, for your reply. I capture the packets and send them here... Best regards, kokoska.rokoska

That's all fine but the call leg does exist? phoneA -- legA ---> FS <--- legB--- phoneB if phoneB leaves and FS did not get a bye legA will never end so naturally when you hangup phoneA you will get a 200ok on it's leg. That is why I asked you for the traces because it's most likely the case that legA is still up because legB is as well and only phoneB thinks the call is over. On Tue, Apr 8, 2008 at 1:15 PM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:

Anthony Minessale napsal(a):

...

yes do you have both a pcap and a console trace of the call.

start freeswitch with TPORT_LOG=1

TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch

set debug level

...

console loglevel debug

capture all the text on the console

I have just updated to current trunk and after a while I do the test and capture all possible dumps

...

my guess without seeing it is that user 22 is behind nat or a proxy or something and you do not have keepalive turned on so the path for the phone on 22 to send the bye to FS is gone so FS is not getting the bye from phone 22

No, no. There is nothing (except ethernet switch :-) between Freeswitch and UACs. They are all on the same lan subnet.

...

We would never say 481 because if FS thinks the call leg should still be up it will last until the call is terminated one way or another.

But if one leg of call was hanged up (and "hangup after bridge" is set) I mean Freeswitch has to hang up second leg and than drop transaction.

...

Remember, each leg of the bridged call is a separate sip call as we are a b2bua.

Yes, I remember it :-) But it IMO have nothing to do with 481. Every UAC or UAS has to be able to send 481 if transaction (call leg) doesn't exists. And from my oppinion most of UAs do it well (better to say, I have never heard about one didn't do it). It is mandatory by RFC3261, 21.4.19 and even Asterisk does it :-)

Thank you, Antohny, for your reply. I capture the packets and send them here...

Best regards,

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

kokoska rokoska napsal(a):

Anthony Minessale napsal(a):

...

That's all fine but the call leg does exist?

phoneA -- legA ---> FS <--- legB--- phoneB

if phoneB leaves and FS did not get a bye legA will never end so naturally when you hangup phoneA you will get a 200ok on it's leg.

That is why I asked you for the traces because it's most likely the case that legA is still up because legB is as well and only phoneB thinks the call is over.

I sent the dump few minutes before...

BTW: Phone B sends BYE, recieves 200 OK and Freeswitch announce hangup on console. But leaves call leg A alive. If I don't use "transfer" app, everything works ok.

Now I'm try to install IRC client and join conference :-)

Regards,

kokoska.rokoska

My e-mail with dump (400 kB) was rejected. How can I send the dump? Regards, kokoska.rokoska

kokoska rokoska napsal(a):

kokoska rokoska napsal(a):

...

Anthony Minessale napsal(a):

...

That's all fine but the call leg does exist?

phoneA -- legA ---> FS <--- legB--- phoneB

if phoneB leaves and FS did not get a bye legA will never end so naturally when you hangup phoneA you will get a 200ok on it's leg.

That is why I asked you for the traces because it's most likely the case that legA is still up because legB is as well and only phoneB thinks the call is over.

I sent the dump few minutes before...

BTW: Phone B sends BYE, recieves 200 OK and Freeswitch announce hangup on console. But leaves call leg A alive. If I don't use "transfer" app, everything works ok.

Now I'm try to install IRC client and join conference :-)

Regards,

kokoska.rokoska

My e-mail with dump (400 kB) was rejected. How can I send the dump?

Regards,

kokoska.rokoska

Here is console dump. regards, kokoska.rokoska 2008-04-08 20:19:50 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [407][Proxy Authentication Required] session: n/a 2008-04-08 20:19:50 [NOTICE] switch_channel.c:531 switch_channel_set_name() New Channel sofia/default/0002*23@192.168.1.128:5065 [0821700d-67c1-46dc-8d9e-8e2b77f8d9a0] 2008-04-08 20:19:50 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [received] 2008-04-08 20:19:50 [DEBUG] sofia.c:1599 sofia_handle_sip_i_state() Remote SDP: v=0 o=- 3416667593 3416667593 IN IP4 192.168.1.101 s=SJphone c=IN IP4 192.168.1.101 t=0 0 m=audio 49152 RTP/AVP 8 101 c=IN IP4 192.168.1.101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=setup:active 2008-04-08 20:19:50 [DEBUG] sofia_glue.c:2011 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMA:8:8000]/[G722:9:8000] 2008-04-08 20:19:50 [DEBUG] sofia_glue.c:2011 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMA:8:8000]/[PCMA:8:8000] 2008-04-08 20:19:50 [DEBUG] sofia_glue.c:1333 sofia_glue_tech_set_codec() Set Codec sofia/default/0002*23@192.168.1.128:5065 PCMA/8000 20 ms 160 samples 2008-04-08 20:19:50 [DEBUG] sofia_glue.c:1975 sofia_glue_negotiate_sdp() Set 2833 dtmf payload to 101 2008-04-08 20:19:50 [DEBUG] sofia.c:1736 sofia_handle_sip_i_state() sofia/default/0002*23@192.168.1.128:5065 State Change CS_NEW -> CS_INIT 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_INIT 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:413 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State INIT 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:80 sofia_on_init() sofia/default/0002*23@192.168.1.128:5065 SOFIA INIT 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:107 sofia_on_init() sofia/default/0002*23@192.168.1.128:5065 State Change CS_INIT -> CS_RING 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:413 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State INIT going to sleep 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_RING 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:119 sofia_on_ring() sofia/default/0002*23@192.168.1.128:5065 SOFIA RING 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:65 switch_core_standard_on_ring() Standard RING sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:50 [INFO] mod_dialplan_xml.c:223 dialplan_hunt() Processing unknown->23@default 2008-04-08 20:19:50 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(23) =~ /^.*$/ 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:96 switch_core_standard_on_ring() sofia/default/0002*23@192.168.1.128:5065 State Change CS_RING -> CS_EXECUTE 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING going to sleep 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_EXECUTE 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:156 sofia_on_execute() sofia/default/0002*23@192.168.1.128:5065 SOFIA EXECUTE 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:128 switch_core_standard_on_execute() Standard EXECUTE 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(forward_counter=1) 2008-04-08 20:19:50 [DEBUG] mod_dptools.c:493 set_function() SET [forward_counter]=[1] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(forward_counter=1) 2008-04-08 20:19:50 [DEBUG] mod_dptools.c:626 export_function() EXPORT [forward_counter]=[1] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute respond(181 Call is being forwarded) 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:990 sofia_receive_message() Responding with 181 Call is being forwarded 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(sip_h_Diversion=<sip:24@192.168.1.128>;reason=uncoditional;counter=1) 2008-04-08 20:19:50 [DEBUG] mod_dptools.c:626 export_function() EXPORT [sip_h_Diversion]=[<sip:24@192.168.1.128>;reason=uncoditional;counter=1] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute transfer(24) 2008-04-08 20:19:50 [DEBUG] switch_ivr.c:1007 switch_ivr_session_transfer() sofia/default/0002*23@192.168.1.128:5065 State Change CS_EXECUTE -> CS_RING 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:50 [NOTICE] switch_ivr.c:1013 switch_ivr_session_transfer() Transfer sofia/default/0002*23@192.168.1.128:5065 to XML[24@default] 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE going to sleep 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_RING 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING 2008-04-08 20:19:50 [DEBUG] mod_sofia.c:119 sofia_on_ring() sofia/default/0002*23@192.168.1.128:5065 SOFIA RING 2008-04-08 20:19:50 [DEBUG] switch_core_state_machine.c:65 switch_core_standard_on_ring() Standard RING sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:50 [INFO] mod_dialplan_xml.c:223 dialplan_hunt() Processing unknown->24@default 2008-04-08 20:19:50 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [181][Call is being forwarded] session: sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(24) =~ /^.*$/ 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:96 switch_core_standard_on_ring() sofia/default/0002*23@192.168.1.128:5065 State Change CS_RING -> CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:156 sofia_on_execute() sofia/default/0002*23@192.168.1.128:5065 SOFIA EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:128 switch_core_standard_on_execute() Standard EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(forward_counter=2) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [forward_counter]=[2] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(forward_counter=2) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [forward_counter]=[2] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute respond(181 Call is being forwarded) 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:990 sofia_receive_message() Responding with 181 Call is being forwarded 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(sip_h_Diversion=<sip:22@192.168.1.128>;reason=uncoditional;counter=2) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [sip_h_Diversion]=[<sip:22@192.168.1.128>;reason=uncoditional;counter=2] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute transfer(22) 2008-04-08 20:19:51 [DEBUG] switch_ivr.c:1007 switch_ivr_session_transfer() sofia/default/0002*23@192.168.1.128:5065 State Change CS_EXECUTE -> CS_RING 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [NOTICE] switch_ivr.c:1013 switch_ivr_session_transfer() Transfer sofia/default/0002*23@192.168.1.128:5065 to XML[22@default] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_RING 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [early] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:119 sofia_on_ring() sofia/default/0002*23@192.168.1.128:5065 SOFIA RING 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:65 switch_core_standard_on_ring() Standard RING sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [INFO] mod_dialplan_xml.c:223 dialplan_hunt() Processing unknown->22@default 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [181][Call is being forwarded] session: sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(22) =~ /^.*$/ 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:96 switch_core_standard_on_ring() sofia/default/0002*23@192.168.1.128:5065 State Change CS_RING -> CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:156 sofia_on_execute() sofia/default/0002*23@192.168.1.128:5065 SOFIA EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:128 switch_core_standard_on_execute() Standard EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(forward_counter=3) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [forward_counter]=[3] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(forward_counter=3) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [forward_counter]=[3] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute respond(181 Call is being forwarded) 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [early] 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:990 sofia_receive_message() Responding with 181 Call is being forwarded 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(sip_h_Diversion=<sip:21@192.168.1.128>;reason=uncoditional;counter=3) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [sip_h_Diversion]=[<sip:21@192.168.1.128>;reason=uncoditional;counter=3] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute transfer(21) 2008-04-08 20:19:51 [DEBUG] switch_ivr.c:1007 switch_ivr_session_transfer() sofia/default/0002*23@192.168.1.128:5065 State Change CS_EXECUTE -> CS_RING 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [NOTICE] switch_ivr.c:1013 switch_ivr_session_transfer() Transfer sofia/default/0002*23@192.168.1.128:5065 to XML[21@default] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_RING 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:119 sofia_on_ring() sofia/default/0002*23@192.168.1.128:5065 SOFIA RING 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:65 switch_core_standard_on_ring() Standard RING sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [INFO] mod_dialplan_xml.c:223 dialplan_hunt() Processing unknown->21@default 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [181][Call is being forwarded] session: sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(21) =~ /^.*$/ 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:96 switch_core_standard_on_ring() sofia/default/0002*23@192.168.1.128:5065 State Change CS_RING -> CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State RING going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:156 sofia_on_execute() sofia/default/0002*23@192.168.1.128:5065 SOFIA EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:128 switch_core_standard_on_execute() Standard EXECUTE 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(dialed_ext=21) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [dialed_ext]=[21] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(dialed_ext=21) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [dialed_ext]=[21] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute export(dst_user=0002*21) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:626 export_function() EXPORT [dst_user]=[0002*21] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(call_timeout=10) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [call_timeout]=[10] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(sip_exclude_contact=${network_addr}) 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [early] 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:984 switch_core_session_execute_application() sofia/default/0002*23@192.168.1.128:5065 Expanded String set(sip_exclude_contact=192.168.1.101) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [sip_exclude_contact]=[192.168.1.101] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(hangup_after_bridge=true) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [hangup_after_bridge]=[true] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute set(continue_on_fail=true) 2008-04-08 20:19:51 [DEBUG] mod_dptools.c:493 set_function() SET [continue_on_fail]=[true] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:139 switch_core_standard_on_execute() sofia/default/0002*23@192.168.1.128:5065 Execute bridge(sofia/default/${dst_user}%192.168.1.128) 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:984 switch_core_session_execute_application() sofia/default/0002*23@192.168.1.128:5065 Expanded String bridge(sofia/default/0002*21%192.168.1.128) 2008-04-08 20:19:51 [NOTICE] switch_channel.c:531 switch_channel_set_name() New Channel sofia/default/0002*21 [0ded99a5-5044-48d2-96ab-66f43af1a03c] 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:1829 sofia_outgoing_channel() sofia/default/0002*21 State Change CS_NEW -> CS_INIT 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*21 Running State Change CS_INIT 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:413 switch_core_session_run() (sofia/default/0002*21) State INIT 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:80 sofia_on_init() sofia/default/0002*21 SOFIA INIT 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [0][INVITE sent] session: sofia/default/0002*21 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:107 sofia_on_init() sofia/default/0002*21 State Change CS_INIT -> CS_RING 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:413 switch_core_session_run() (sofia/default/0002*21) State INIT going to sleep 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*21 entering state [calling] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*21 Running State Change CS_RING 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*21) State RING 2008-04-08 20:19:51 [DEBUG] mod_sofia.c:119 sofia_on_ring() sofia/default/0002*21 SOFIA RING 2008-04-08 20:19:51 [DEBUG] switch_ivr_originate.c:55 originate_on_ring() sofia/default/0002*21 State Change CS_RING -> CS_HOLD 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:418 switch_core_session_run() (sofia/default/0002*21) State RING going to sleep 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*21 Running State Change CS_HOLD 2008-04-08 20:19:51 [DEBUG] switch_core_state_machine.c:440 switch_core_session_run() (sofia/default/0002*21) State HOLD 2008-04-08 20:19:51 [DEBUG] switch_ivr_originate.c:951 switch_ivr_originate() Raw Codec Activation Success L16@8000hz 1 channel 20ms 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_r_invite] status [180][Ringing] session: sofia/default/0002*21 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [180][Ringing] session: sofia/default/0002*21 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*21 entering state [proceeding] 2008-04-08 20:19:51 [NOTICE] sofia.c:1633 sofia_handle_sip_i_state() Ring-Ready sofia/default/0002*21! 2008-04-08 20:19:51 [NOTICE] mod_sofia.c:1017 sofia_receive_message() Ring-Ready sofia/default/0002*23@192.168.1.128:5065! 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [NOTICE] switch_ivr_originate.c:1026 switch_ivr_originate() Ring Ready sofia/default/0002*23@192.168.1.128:5065! 2008-04-08 20:19:51 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:51 [DEBUG] sofia.c:219 sofia_event_callback() event [nua_i_state] status [180][Ringing] session: sofia/default/0002*23@192.168.1.128:5065 2008-04-08 20:19:51 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [early] 2008-04-08 20:19:53 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*21 entering state [ready] 2008-04-08 20:19:53 [DEBUG] sofia.c:1599 sofia_handle_sip_i_state() Remote SDP: v=0 o=- 18939677 18939677 IN IP4 192.168.1.151 s=- c=IN IP4 192.168.1.151 t=0 0 m=audio 16424 RTP/AVP 8 100 101 a=rtpmap:8 PCMA/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2008-04-08 20:19:53 [DEBUG] sofia_glue.c:2011 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMA:8:8000]/[PCMA:8:8000] 2008-04-08 20:19:53 [DEBUG] sofia_glue.c:1333 sofia_glue_tech_set_codec() Set Codec sofia/default/0002*21 PCMA/8000 20 ms 160 samples 2008-04-08 20:19:53 [DEBUG] sofia_glue.c:1975 sofia_glue_negotiate_sdp() Set 2833 dtmf payload to 101 2008-04-08 20:19:53 [DEBUG] sofia_glue.c:1523 sofia_glue_activate_rtp() AUDIO RTP [sofia/default/0002*21] 192.168.1.128:26702->192.168.1.151:16424 codec: 8 ms: 20 2008-04-08 20:19:53 [DEBUG] switch_rtp.c:716 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-04-08 20:19:53 [DEBUG] switch_channel.c:1506 switch_channel_perform_mark_answered() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:53 [NOTICE] sofia.c:1945 sofia_handle_sip_i_state() Channel [sofia/default/0002*21] has been answered 2008-04-08 20:19:53 [DEBUG] sofia_glue.c:1523 sofia_glue_activate_rtp() AUDIO RTP [sofia/default/0002*23@192.168.1.128:5065] 192.168.1.128:22042->192.168.1.101:49152 codec: 8 ms: 20 2008-04-08 20:19:53 [DEBUG] switch_rtp.c:716 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-04-08 20:19:53 [DEBUG] mod_sofia.c:376 sofia_answer_channel() Local SDP sofia/default/0002*23@192.168.1.128:5065: v=0 o=FreeSWITCH 1207656751 1207656752 IN IP4 192.168.1.128 s=FreeSWITCH c=IN IP4 192.168.1.128 t=0 0 a=sendrecv m=audio 22042 RTP/AVP 8 101 13 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 2008-04-08 20:19:53 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:53 [NOTICE] switch_ivr_originate.c:1171 switch_ivr_originate() Channel [sofia/default/0002*23@192.168.1.128:5065] has been answered 2008-04-08 20:19:53 [DEBUG] switch_ivr_originate.c:1205 switch_ivr_originate() Originate Resulted in Success: [sofia/default/0002*21] 2008-04-08 20:19:53 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:19:53 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:19:53 [DEBUG] switch_ivr_bridge.c:756 switch_ivr_multi_threaded_bridge() sofia/default/0002*21 State Change CS_HOLD -> CS_LOOPBACK 2008-04-08 20:19:53 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:19:53 [DEBUG] switch_core_state_machine.c:440 switch_core_session_run() (sofia/default/0002*21) State HOLD going to sleep 2008-04-08 20:19:53 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*21 Running State Change CS_LOOPBACK 2008-04-08 20:19:53 [DEBUG] switch_core_state_machine.c:431 switch_core_session_run() (sofia/default/0002*21) State LOOPBACK 2008-04-08 20:19:53 [DEBUG] mod_sofia.c:314 sofia_on_loopback() SOFIA LOOPBACK 2008-04-08 20:19:53 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [completed] 2008-04-08 20:19:53 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*23@192.168.1.128:5065 entering state [ready] 2008-04-08 20:20:08 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/0002*21 entering state [terminated] 2008-04-08 20:20:08 [NOTICE] sofia.c:1992 sofia_handle_sip_i_state() Hangup sofia/default/0002*21 [CS_LOOPBACK] [NORMAL_CLEARING] 2008-04-08 20:20:08 [DEBUG] switch_channel.c:1355 switch_channel_perform_hangup() Kill sofia/default/0002*21 [KILL] 2008-04-08 20:20:08 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:20:08 [DEBUG] switch_ivr_bridge.c:275 audio_bridge_thread() read: sofia/default/0002*21 Bad Frame.... Bubye! 2008-04-08 20:20:08 [DEBUG] switch_ivr_bridge.c:344 audio_bridge_thread() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:20:08 [DEBUG] switch_ivr_bridge.c:347 audio_bridge_thread() BRIDGE THREAD DONE [sofia/default/0002*21] 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:431 switch_core_session_run() (sofia/default/0002*21) State LOOPBACK going to sleep 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*21 Running State Change CS_HANGUP 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/0002*21) State HANGUP 2008-04-08 20:20:08 [DEBUG] mod_sofia.c:255 sofia_on_hangup() Channel sofia/default/0002*21 hanging up, cause: NORMAL_CLEARING 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/default/0002*21, cause: NORMAL_CLEARING 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/0002*21) State HANGUP going to sleep 2008-04-08 20:20:08 [DEBUG] switch_core_session.c:730 switch_core_session_thread() Session 2 (sofia/default/0002*21) Locked, Waiting on external entities 2008-04-08 20:20:08 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:20:08 [DEBUG] switch_ivr_bridge.c:344 audio_bridge_thread() Kill sofia/default/0002*21 [BREAK] 2008-04-08 20:20:08 [DEBUG] switch_ivr_bridge.c:347 audio_bridge_thread() BRIDGE THREAD DONE [sofia/default/0002*23@192.168.1.128:5065] 2008-04-08 20:20:08 [NOTICE] switch_ivr_bridge.c:802 switch_ivr_multi_threaded_bridge() Hangup sofia/default/0002*23@192.168.1.128:5065 [CS_EXECUTE] [NORMAL_CLEARING] 2008-04-08 20:20:08 [DEBUG] switch_channel.c:1355 switch_channel_perform_hangup() Kill sofia/default/0002*23@192.168.1.128:5065 [KILL] 2008-04-08 20:20:08 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/0002*23@192.168.1.128:5065 [BREAK] 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State EXECUTE going to sleep 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/0002*23@192.168.1.128:5065 Running State Change CS_HANGUP 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State HANGUP 2008-04-08 20:20:08 [DEBUG] mod_sofia.c:255 sofia_on_hangup() Channel sofia/default/0002*23@192.168.1.128:5065 hanging up, cause: NORMAL_CLEARING 2008-04-08 20:20:08 [NOTICE] switch_core_session.c:748 switch_core_session_thread() Session 2 (sofia/default/0002*21) Ended 2008-04-08 20:20:08 [NOTICE] switch_core_session.c:750 switch_core_session_thread() Close Channel sofia/default/0002*21 [CS_HANGUP] 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/default/0002*23@192.168.1.128:5065, cause: NORMAL_CLEARING 2008-04-08 20:20:08 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/0002*23@192.168.1.128:5065) State HANGUP going to sleep 2008-04-08 20:20:08 [DEBUG] switch_core_session.c:730 switch_core_session_thread() Session 1 (sofia/default/0002*23@192.168.1.128:5065) Locked, Waiting on external entities 2008-04-08 20:20:08 [NOTICE] switch_core_session.c:748 switch_core_session_thread() Session 1 (sofia/default/0002*23@192.168.1.128:5065) Ended 2008-04-08 20:20:08 [NOTICE] switch_core_session.c:750 switch_core_session_thread() Close Channel sofia/default/0002*23@192.168.1.128:5065 [CS_HANGUP]

Michael Jerris napsal(a):

This issue is now fixed in svn trunk:

http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=8062

fix hung channels when using respond app with 1xx or 2xx responses or on re-invite in proxy/bypass media with 1xx and 2xx responses

Mike

Thank you very much, Michael, for that info! I have just updated to current trunk and everything seems to be ok. Many thanks, regards kokoska.rokoska

The NDLB-connectile-dysfunction is a paramater to explicitly break the rfc and re-write our behavior as if we got a contact of the same address that we received the packet from. If it comes from 5060, it will have 5060 in the contact. If you would like to handle nat and still be rfc compliant, then you need to use a client that follows the rfc's so you don't have to use non compliant hacks. Mike On Apr 10, 2008, at 2:42 PM, kokoska rokoska wrote:

Hi all, I'm back and the bug too :-)

Now I try to setup NAT handling:

<variable name='sip-force-contact' value='NDLB-connectile- dysfunction'/>

and FreeSWITCH starts to rewrite contact (append port 5060) like in previous case...

Best regards,

kokoska.rokoska

kokoska rokoska napsal(a):

...

Hi all,

I just start to play with Freeswitch and first thing I discover is bad REGISTER processing in mod_sofia :-(

The problem is, that Sofia modifies Contact header (append port 5060 which is not in original REGISTER request) in 200 OK reply and thus a ot of clients refuses it (for example SJPhone, Nokia E series etc.). Full debug is included at the end of my e-mail.

In this manner Freeswitch behaviour IMO violates rfc3261:

19.1.4 URI Comparison ...

A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components.

Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. ...

Could you please tell me how to configure mod_sofia to properly handle REGISTER request?

Thanx a lot, regards

kokoska.rokoska

---------------------------- SIP debug made with SJPhone:

2008-04-06 08:26:36.093 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001e47f8893c000053f900000006;rport From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065> Contact: <sip:1000@192.168.1.101> Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 3 REGISTER Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0

2008-04-06 08:26:36.109 UDP 192.168.1.128:5065->LOCAL SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001e47f8893c000053f900000006;rport=5060

From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065>;tag=vHv1X7K9yemUe Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 3 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer WWW-Authenticate: Digest realm="192.168.1.128", nonce="3a4ee704-f9a9-4789-9853-e8e8d6b562e9", algorithm=MD5, qop="auth" Content-Length: 0

2008-04-06 08:26:36.109 UDP LOCAL->192.168.1.128:5065 REGISTER sip:192.168.1.128:5065 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001f47f8893c00007cb100000008;rport From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065> Contact: <sip:1000@192.168.1.101> Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 4 REGISTER Max-Forwards: 70 User-Agent: SJphone/1.65.377a (SJ Labs) Content-Length: 0 Authorization: Digest username="1000",realm="192.168.1.128",nonce="3a4ee704- f9a9-4789-9853-e8e8d6b562e9",uri="sip: 192.168.1.128 : 5065 ",response = "cd1a36378bdb3efaabcfa263a6b9f24c ",algorithm=MD5,cnonce="5536ed3a7",qop=auth,nc=00000001

2008-04-06 08:26:36.109 UDP 192.168.1.128:5065->LOCAL SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.101 ;branch=z9hG4bKc0a801650000001f47f8893c00007cb100000008;rport=5060

From: "unknown" <sip:1000@192.168.1.128:5065>;tag=42f1ed397 To: <sip:1000@192.168.1.128:5065>;tag=XtNtZ24cvQaea Call-ID: 02C388469A134FC18B97E294E4BD845C0xc0a80165 CSeq: 4 REGISTER Contact: "user" <sip:1000@192.168.1.101:5060>;expires=60 User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer Content-Length: 0

10:26:36 SIP.Registration WARNING Registrar did not registered none of our contacts! 10:26:36 SIP.Registration NOTICE Foreign contacts returned by the server: sip:1000@192.168.1.101:5060 10:26:36 SIP.Registration INFO Not registered sip:1000@192.168.1.128:5065 10:26:36 SIP.RegistrationClient INFO Registration reattempt scheduled after 60 seconds 10:26:36 SIP.Network DEBUG 2008-04-06 08:26:36.234 UDP 192.168.1.128:5065->LOCAL NOTIFY sip:1000@192.168.1.101:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.128:5065;rport;branch=z9hG4bKc5ZBa6F96yHee Max-Forwards: 70 From: <sip:1000@192.168.1.128>;tag=y3eK1XNgS000N To: <sip:1000@192.168.1.128> Call-ID: feef82f8-7e55-122b-fb8d-000854d1424f CSeq: 97616858 NOTIFY Contact: <sip:mod_sofia@192.168.1.128:5065> User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8038 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer Event: message-summary Subscription-State: terminated;timeout Content-Type: application/simple-message-summary Content-Length: 65

Messages-Waiting: no Message-Account: sip:1000@192.168.1.128

10:26:36 SIP.Network DEBUG 2008-04-06 08:26:36.234 UDP LOCAL->192.168.1.128:5065 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.128 :5065;branch=z9hG4bKc5ZBa6F96yHee;rport=5065;received=192.168.1.128

From: <sip:1000@192.168.1.128>;tag=y3eK1XNgS000N To: "unknown" <sip:1000@192.168.1.128>;tag=6c19ed424 Call-ID: feef82f8-7e55-122b-fb8d-000854d1424f CSeq: 97616858 NOTIFY Content-Length: 0 Server: SJphone/1.65.377a (SJ Labs)

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org

Just for completion of my previous e-mail: May be I miss something significant and all my thesis are completly wrong. If yes, I apologize and ask you for correction of my thoughts :-) Thank you. Best regards, kokoska.rokoska kokoska rokoska napsal(a):

Thank you very much, Michael, for your answer!

My comments are included in the e-mail body:

Michael Jerris napsal(a):

...

The NDLB-connectile-dysfunction is a paramater to explicitly break the rfc

My be, but only internaly - i.e. all your public communication could be RFC compliant if you want.

...

and re-write our behavior as if we got a contact of the same address that we received the packet from.

Yes, in the same manner as all VoIP TSP (at least all bigger VoIP TSP in Europe) do :-)

...

If it comes from 5060, it will have 5060 in the contact.

And this brakes the RFC and UAC should refuse your 200 OK. There are a lot of broken clients which accepts this but not all of them :-)

...

If you would like to handle nat and still be rfc compliant, then you need to use a client that follows the rfc's

I'm sorry but I don't know what is RFC noncomplient if UAC behind NAT sends private IP in contact. Could you point me to relevant part of some RFC, please? It will be very helpful for me...

...

so you don't have to use non compliant hacks.

Like I wrote before, I can't remember any real (and not marginal) VoIP telco provider in Europe which doesn't internaly rewrite contact URI in case of UAC behind NAT. Even thou, a lot of them rewrite EVERY contact URI and don't try to detect NAT, because a lot of SOHO routers have SIP-ALG support (god dammed) which makes thing even complicated.

But there is - IMO - no reason why to rewrite contact URI in 200 OK response to REGISTER request.

----------------

All at all, from my point of view there is a big drawback if I couldn't use FreeSWITCH for UACs behind NAT. It forces me to use OpenSER as registrar (what I want to avid to because of performance and harder setup to keep good interoperability) which has no problem with clients behind NAT.

I believe that improvement in NAT handling could help FreeSWITCH users a lot. Thus I will be glad to help you as much as I can do. Please let me know if I can do something handy (other than rewrite FS by myself :-).

Thanks once more, Michael, for your answer!

Best regards,

kokoska.rokoska

_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org