Why does a SIP forked dial select just the first 183?
Hi, I read in: http://wiki.freeswitch.org/wiki/Dialplan_Recipes the following: ----------------------- = Forked dial example = Forked dial is when you want to attempt to ring 2 destinations at the same time. Freeswitch will attempt to call both bridge options simultaneously. The first bridge leg that replies with a 183 (session progress) message will win the call, and the other bridge leg is dropped. This only will work with late_negotiation enabled. ----------------------- While the above could be valid when sending calls to varios (just two?) PSTN gateways, I wonder why I couldn't send a call to two local users (200 and 201) and wait until one of them *answers*. My expected behaviour is: - I call to FS extension 500. - FS does a bridge to 200 and 201. - 200 replies 180 "Ringing" - 201 replies 183 "Session Progress" with early media (not very common in a SIP phone but possible anyway) - After a while 200 replies a 200 OK so FS sends a CANCEL to 201 and replies 200 OK to the caller. Is this common behaviour not possible in FS? is there othe way to get it instead of using "bridge" app with two destinations in "data"? Thanks. -- Iñaki Baz Castillo <ibc@aliax.net>
Disable 100rel on the sofia profile or update to latest SVN trunk. We have an issue on jira about this already and are working with the sofia team on this issue. The solution is to disable 100REL and it'll quit doing that. /b On Nov 20, 2008, at 3:13 AM, Iñaki Baz Castillo wrote:
Hi, I read in: http://wiki.freeswitch.org/wiki/Dialplan_Recipes the following:
----------------------- = Forked dial example = Forked dial is when you want to attempt to ring 2 destinations at the same time. Freeswitch will attempt to call both bridge options simultaneously. The first bridge leg that replies with a 183 (session progress) message will win the call, and the other bridge leg is dropped. This only will work with late_negotiation enabled. -----------------------
While the above could be valid when sending calls to varios (just two?) PSTN gateways, I wonder why I couldn't send a call to two local users (200 and 201) and wait until one of them *answers*. My expected behaviour is:
- I call to FS extension 500. - FS does a bridge to 200 and 201. - 200 replies 180 "Ringing" - 201 replies 183 "Session Progress" with early media (not very common in a SIP phone but possible anyway) - After a while 200 replies a 200 OK so FS sends a CANCEL to 201 and replies 200 OK to the caller.
Is this common behaviour not possible in FS? is there othe way to get it instead of using "bridge" app with two destinations in "data"?
Thanks.
if you want to wait for the first one to answer instead of indicate progress you add {ignore_early_media=true} to the beginning of the dial string <action application="bridge" data="{ignore_early_media=true}sofa/profile/ 200@dom.com,sofia/profile/201@dom.com"/> On Thu, Nov 20, 2008 at 3:13 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi, I read in: http://wiki.freeswitch.org/wiki/Dialplan_Recipes the following:
----------------------- = Forked dial example = Forked dial is when you want to attempt to ring 2 destinations at the same time. Freeswitch will attempt to call both bridge options simultaneously. The first bridge leg that replies with a 183 (session progress) message will win the call, and the other bridge leg is dropped. This only will work with late_negotiation enabled. -----------------------
While the above could be valid when sending calls to varios (just two?) PSTN gateways, I wonder why I couldn't send a call to two local users (200 and 201) and wait until one of them *answers*. My expected behaviour is:
- I call to FS extension 500. - FS does a bridge to 200 and 201. - 200 replies 180 "Ringing" - 201 replies 183 "Session Progress" with early media (not very common in a SIP phone but possible anyway) - After a while 200 replies a 200 OK so FS sends a CANCEL to 201 and replies 200 OK to the caller.
Is this common behaviour not possible in FS? is there othe way to get it instead of using "bridge" app with two destinations in "data"?
Thanks.
-- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users 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
2008/11/20 Anthony Minessale <anthony.minessale@gmail.com>:
if you want to wait for the first one to answer instead of indicate progress you add {ignore_early_media=true} to the beginning of the dial string <action application="bridge" data="{ignore_early_media=true}sofa/profile/200@dom.com,sofia/profile/201@dom.com"/>
Great, but does it mean that the early media will not arrive to the caller? This is: - alice calls to extension 5000. - FS does a parallel call to bob and carol with ignore_early_media=true. - bob replies 183 with SDP while carol just a 100 Trying for now. - I expect that FS would choose the SDP from bob and send it back to alice. Will it be the behaviour with ignore_early_media=true ? Or will FS drop the 183 and send "nothing" to the caller? Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
You have a catch-22 in this situation, which media path would you want to pass along as you may have multiple? I think in this situation we pass the media of the first media connection that we setup unless you configure for fs to generate the ringback. Mike On Nov 20, 2008, at 10:18 AM, Iñaki Baz Castillo wrote:
2008/11/20 Anthony Minessale <anthony.minessale@gmail.com>:
if you want to wait for the first one to answer instead of indicate progress you add {ignore_early_media=true} to the beginning of the dial string <action application="bridge" data="{ignore_early_media=true}sofa/profile/200@dom.com,sofia/profile/201@dom.com "/>
Great, but does it mean that the early media will not arrive to the caller? This is:
- alice calls to extension 5000. - FS does a parallel call to bob and carol with ignore_early_media=true. - bob replies 183 with SDP while carol just a 100 Trying for now. - I expect that FS would choose the SDP from bob and send it back to alice.
Will it be the behaviour with ignore_early_media=true ? Or will FS drop the 183 and send "nothing" to the caller?
Thanks a lot.
-- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
2008/11/20 Michael Jerris <mike@jerris.com>:
You have a catch-22 in this situation, which media path would you want to pass along as you may have multiple?
Yes, this is also an undocumented "feature" of SIP and each implementation chooses what to do. Normally the devices choose the first early media and just render it to the user.
I think in this situation we pass the media of the first media connection that we setup unless you configure for fs to generate the ringback.
Yes, I hope this is the behaviour. It's the "most" correct (or "less" incorrect XD). Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
We are not a proxy we are a b2bua so we are not going to send bob or carols sdp to alice alice and FS have a private sdp between them. We are not doing SIP forked dialing here, we are doing FS forked dialing that is designed to be protocol agnostic. Keep that in mind because it's important to not lose track that we are not a sip switch rather a protocol agnostic soft switch. When either bob or carol send a 18X to mod_sofia their respective FS channel will translate it into FS specific code of either RING_READY(progress w/o media) or EARLY_MEDIA(progress w/ media) if it gets RING_READY it will in turn mark alice's channel RING_READY which will translate back into 180 to her phone. If it gets an EARLY_MEDIA it will translate back into a 183 and establish early media between FS and alice. If ignore_early_media is true the calls will continue to proceed and if alice has the variable "ringback" set to a tone description or media file that file/tone will begin to play until bob or carol answer. If it's not set then whichever one establishes 183 first will end the forked dial and alice will be bridged to that unanswerd call and hear the early media. Again for good measure, we do not do SIP specific forked dialing/proxy fantasy that alice and bob and the white rabbit are having with the cattipilar and his hooka. I am glad you are here to provide a check and balance be be sure to respect my decisions no how the software works and you will be a welcome addition to our community. I will just warn you that too much SIP zealotry will piss me off no matter how nicely put. I am not worried about this because you have already admitted that the RFC was written by martians. =D On Thu, Nov 20, 2008 at 9:18 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2008/11/20 Anthony Minessale <anthony.minessale@gmail.com>:
if you want to wait for the first one to answer instead of indicate progress you add {ignore_early_media=true} to the beginning of the dial string <action application="bridge" data="{ignore_early_media=true}sofa/profile/200@dom.com,sofia/profile/ 201@dom.com"/>
Great, but does it mean that the early media will not arrive to the caller? This is:
- alice calls to extension 5000. - FS does a parallel call to bob and carol with ignore_early_media=true. - bob replies 183 with SDP while carol just a 100 Trying for now. - I expect that FS would choose the SDP from bob and send it back to alice.
Will it be the behaviour with ignore_early_media=true ? Or will FS drop the 183 and send "nothing" to the caller?
Thanks a lot.
-- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users 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
2008/11/20 Anthony Minessale <anthony.minessale@gmail.com>:
Again for good measure, we do not do SIP specific forked dialing/proxy fantasy that alice and bob and the white rabbit are having with the cattipilar and his hooka. I am glad you are here to provide a check and balance be be sure to respect my decisions no how the software works and you will be a welcome addition to our community. I will just warn you that too much SIP zealotry will piss me off no matter how nicely put. I am not worried about this because you have already admitted that the RFC was written by martians. =D
Well, I just would like to say that everything I could suggest/report about SIP is because I consider it really useful and important, I will never ask for any "exotic" feature of SIP that nobody wants (except whitepapers-writers). RFC 3261 (being the SIP core) is really full of useless and super-complex features that nobody wants to implement, but IETF people remain considering them as "used" instead of accept dropping them. And if we talk about other SIP related RFC's and drafts.... mmm... But SIP has also cool things ;) BTW, since FS is a B2BUA (and there is not specifications for B2BUA, except "B2BUA = UAS + UAC"), then the FS behaviour is "free", and I hope it's open to include **useful** features ;) PD: As a suggestion FS should implement S/MIME. PPD: ...it's a joke XDD Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
participants (4)
-
Anthony Minessale
-
Brian West
-
Iñaki Baz Castillo
-
Michael Jerris