Hi Anthony, please find attached the patch. It will add a variable called "forward_180_after_183". If this is set (and exported!) to true, it will pass-through the Ringing from B to A. I had another idea why the behavior is necessary: B could send a session progress but B (a SBC) does not really know, if the call will be ever in RINGING state towards the other party. Maybe the other party on B is not reachable and therefore the SBC does forward a informational message over RTP of the pre-answered (Session Progress 183) call to FS that the member is not reachable. In another case the call party of B is reachable and therefore the SBC does forward RINGING. I know that the main problem of this, is the flexible interpretation of the SIP protocol where all the different device manufacture try to read it different. Best regards, Bernhard Suttner -----Ursprüngliche Nachricht----- Von: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] Im Auftrag von Anthony Minessale Gesendet: Donnerstag, 4. November 2010 23:18 An: freeswitch-dev@lists.freeswitch.org Betreff: Re: [Freeswitch-dev] Session Progress and RINGING try to patch it i guess. I still say the RFC is to vague to call this behavior complying with the RFC. if you can make a clean patch that we can wrap in a pram like support-one-of-many-interpretation-of-rfc3960=true On Thu, Nov 4, 2010 at 5:05 PM, Bernhard Suttner <bernhard.suttner@winet.ch> wrote:
We will try that out but its not "100%" the functionality as the sbc does signalize. If I understand you correct, the 183 with SDP will be forwarded to A with 180 with SDP. But this does change the functionality to A (first of all on SIP/ISDN gateways).
Therefore I would prefer the "clean" way with RFC 3960.
Would you include a patch like "support-rfc3960" configuration option to sofia config which will ignore the CF_EARLY_MEDIA test?
----- Original Message ----- From: Anthony Minessale [mailto:anthony.minessale@gmail.com] To: freeswitch-dev@lists.freeswitch.org Sent: Thu, 04 Nov 2010 22:54:34 +0100 Subject: Re: [Freeswitch-dev] Session Progress and RINGING
how about what I said: {ignore_early_media=ring_ready}
On Thu, Nov 4, 2010 at 4:29 PM, Bernhard Suttner <bernhard.suttner@winet.ch> wrote:
Hi,
yes, they are not really sure but I think that the given RFC does specify this correctly (this does not mean, that all the SIP devices work like that). I could understand that a change will maybe result in big troubles. Perhaps a option for mod_sofia to "support-rfc3960" would be a good solution. If you want I will write the patch because it should be "really simple" to ignore the CF_EARLY_MEDIA if the option is set, or?
We get the Session Progress with SDP and later the 180 Ringing from a session border controller (I am not 100% sure, but I think its a a Audiocodes). The 180 Ringing has to be sent towards A because A is a ISDN gateway.
Would do you prefer? Thanks for your investigation.
Best regards, Bernhard Suttner
----- Original Message ----- From: Anthony Minessale [mailto:anthony.minessale@gmail.com] To: freeswitch-dev@lists.freeswitch.org Sent: Thu, 04 Nov 2010 22:09:48 +0100 Subject: Re: [Freeswitch-dev] Session Progress and RINGING
My conclusion from reading that discussion is they have no idea what to do. There are votes both ways and 2 attempts to go of onto a tangent into another topic.
We have chosen on our implementation to ignore 180 once we have already established a media path from a 183. The RFC is just vague enough that this decision falls to us.
I understand that ISDN has more precise signaling in this regard. PROGRESS or ALERTING both with or without media as a flag on the packet.
But the vast majority of SIP devices in the wild will ignore the 180 once early media has been established. So even if we make changes to support this, it will be ignored by the next guy in line.
Do you hear media during this early media phase?
This is why we have the originate param {ignore_early_media=ring_ready} which will, in the case of sip, translate 183 or 180 with and without SDP into a 180
To change it to do what you are asking for could have extreme negative side effects and not even work in most devices so this is why I am reluctant to change it.
Are you trying to cross connect 2 ISDN lines over SIP and preserve the signalling? If so, this is why SIP is flawed to begin with because it is lossy in telephony signaling data. This is why they now try to embed ss7 messages in the sip packets. =p
On Thu, Nov 4, 2010 at 3:51 PM, Bernhard Suttner <bernhard.suttner@winet.ch> wrote:
Hi,
session progress does have SDP which will then go through to A. But on the display of A it will only display "session progress" and not Ringing. If A is now a ISDN Gateway and has to signalize RINGING into the "ISDN world". I am not sure, if RINGING will be used for A to generate the ringback tone for itself on every device. This behaves on the client/device configuration.
There was a nice discussion about this "issue" on the sip-implementors list:
http://www.mail-archive.com/sip-implementors@lists.cs.columbia.edu/msg06400....
There is a RFC for this case (Section: 3.2. Ringing Tone Generation) http://www.rfc-editor.org/rfc/rfc3960.txt
What do you think?
Best regards, Bernhard Suttner
----- Original Message ----- From: Anthony Minessale [mailto:anthony.minessale@gmail.com] To: freeswitch-dev@lists.freeswitch.org Sent: Thu, 04 Nov 2010 16:54:30 +0100 Subject: Re: [Freeswitch-dev] Session Progress and RINGING
no, once it gets session progress it will not send any ringing. The sip side 180 ringing is used to tell the phone to generate its own inband ringing.
does your 183 session progress contain a sdp?
On Thu, Nov 4, 2010 at 10:25 AM, Bernhard Suttner <bernhard.suttner@winet.ch> wrote: > Hi, > > A ---> FS ---> B > > B does send a Session Progress to FS. FS will forward the Session
Progress
to A. > B does send a RINGING to FS. FS does _not_ forward this to A. > > Could it be, that the check the switch_test_flag(channel, CF_EARLY_MEDIA) in mod_sofia.c within the INDICATE_RINGING section is wrong. I think it is allowed to send the Session Progress first and later the RINGING. The ringing is for example for SIP/ISDN gateways necessary. > > Any hint is appreciated. > > Best regards, > Bernhard Suttner > > > > _______________________________________________ > 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire
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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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/ Twitter: http://twitter.com/FreeSWITCH_wire 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 googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _______________________________________________ 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