Hi, I'm starting with FS and still don't handle very well the dialplan syntax, but anyway I've realized that FS is not suitable for sending MESSAGE (instead of INVITE). I've registered two "internal" users (the default config): 1000 and 1001: a) INVITE between internal users: - 1000 calls 1001 - FS asks for authentication - 1000 resends the INVITE with authorization headers. - FS calls 1001 - 1001 answers - FS brigdes the call by sending 200 to 1000. b) INVITE to external user: - 1000 calls sip:bob@external_domain.com - FS asks for authentication - 1000 resends the INVITE with authorization headers. - FS replies 404. c) MESSAGE between internal users: - 1000 sends MESSAGE to 1001 - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS sends the MESSAGE to 1001 - 1001 replies 200 OK to FS d) MESSAGE to external user: - 1000 sends MESSAGE to sip:bob@external_domain.com - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS ***doesn't*** send the MESSAGE to the destination user. Well, I think it's obvious that FS MESSAGE handling is not coherent. Opinions? is there something to do? Thanks. -- Iñaki Baz Castillo <ibc@aliax.net>
On Nov 19, 2008, at 4:12 AM, Iñaki Baz Castillo wrote:
Hi, I'm starting with FS and still don't handle very well the dialplan syntax, but anyway I've realized that FS is not suitable for sending MESSAGE (instead of INVITE).
I've registered two "internal" users (the default config): 1000 and 1001:
a) INVITE between internal users: - 1000 calls 1001 - FS asks for authentication - 1000 resends the INVITE with authorization headers. - FS calls 1001 - 1001 answers - FS brigdes the call by sending 200 to 1000.
b) INVITE to external user: - 1000 calls sip:bob@external_domain.com - FS asks for authentication - 1000 resends the INVITE with authorization headers. - FS replies 404.
You're not fully understanding FreeSWITCH yet... You also have to catch this scenario in the dialplan. <extension name="external_sip_uri" continue="true"> <condition field="source" expression="mod_sofia"/> <condition field="${domain_exists(${sip_req_host})}" expression="true"> <anti-action application="bridge" data="sofia/internal/$ {sip_to_uri}"/> </condition> </extension> Something like that would work and its commented out in the defaults. Remember we aren't a proxy. So your phone is sending the invite directed at FreeSWITCH looking for bob in the context and since it can't find it... 404 not found. The above example checks if the sip_req_host is a local domain.. if not then lets send it out.
c) MESSAGE between internal users: - 1000 sends MESSAGE to 1001 - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS sends the MESSAGE to 1001 - 1001 replies 200 OK to FS
<param name="auth-all-packets" value="true"/> B2BUA still.
d) MESSAGE to external user: - 1000 sends MESSAGE to sip:bob@external_domain.com - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS ***doesn't*** send the MESSAGE to the destination user.
To route you must use the sip+user@domain.com to route this stuff properly since we can bridge various technologies together. If you search the mailing list Mike Jerris explained this in detail about a week or so ago. /b
Well, I think it's obvious that FS MESSAGE handling is not coherent. Opinions? is there something to do?
Thanks.
2008/11/19 Brian West <brian@freeswitch.org>:
You're not fully understanding FreeSWITCH yet... You also have to catch this scenario in the dialplan. <extension name="external_sip_uri" continue="true"> <condition field="source" expression="mod_sofia"/> <condition field="${domain_exists(${sip_req_host})}" expression="true"> <anti-action application="bridge" data="sofia/internal/${sip_to_uri}"/> </condition> </extension> Something like that would work and its commented out in the defaults. Remember we aren't a proxy. So your phone is sending the invite directed at FreeSWITCH looking for bob in the context and since it can't find it... 404 not found. The above example checks if the sip_req_host is a local domain.. if not then lets send it out.
Thanks, but I still don't understand why I don't get a 404 when I send a MESSAGE to an external user. I understand this is a B2BUA, and AFAIF the behaviour is: 1) Transparent B2BUA for INVITE (no PlayBack, announce...). Call success: 1000 (dialog 1) FS (dialog 2) 1001 INVITE ---------------> INVITE ---------------> <------------------- 200 <------------------- 200 ACK ------------------> ACK ------------------> 2) Transparent B2BUA for INVITE (no PlayBack, announce...). Call NO success: 1000 (dialog 1) FS (dialog 2) 1001 INVITE ---------------> INVITE ---------------> <------------------- 486 <------------------- 486 ACK ------------------> ACK ------------------> 3) Transparent B2BUA for MESSAGE. Success: 1000 (leg 1) FS (leg 2) 1001 MESSAGE ------------> MESSAGE --------> <------------------- 200 <------------------- 200 4) Transparent B2BUA for MESSAGE. NO Success: 1000 (leg 1) FS (leg 2) 1001 MESSAGE ------------> MESSAGE --------> <------------------- 4XX <------------------- 4XX But it seems that FS always replies 200 to the MESSAGE in leg A even if FS is not capable of delivering it to a remote destination. In my previous mail, when I send a MESSAGE to an external user, FS accepts the MESSAGE and replies directly 200 OK, so the user expects the MESSAGE has been received by the *remote* user (the user sending the MESSAGE doesn't care if FS is a pure SIP proxy or a B2BUA).
c) MESSAGE between internal users: - 1000 sends MESSAGE to 1001 - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS sends the MESSAGE to 1001 - 1001 replies 200 OK to FS
<param name="auth-all-packets" value="true"/>
Great! Thanks.
d) MESSAGE to external user: - 1000 sends MESSAGE to sip:bob@external_domain.com - FS ***doesn't** ask for authentication <---- !!!!!!! - FS replies 200 OK directly - FS ***doesn't*** send the MESSAGE to the destination user.
To route you must use the sip+user@domain.com to route this stuff properly since we can bridge various technologies together.
Sorry, is it a typo and you mean "sip:user@domain.com"?
If you search the mailing list Mike Jerris explained this in detail about a week or so ago.
I will search for it, thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
participants (2)
-
Brian West
-
Iñaki Baz Castillo