4a4670a71ea43306c944ebe87828f105fcc59451 from git /Peter ________________________________________ Från: freeswitch-users-bounces@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för peely [freeswitch@peely.com] Skickat: den 6 juni 2010 21:14 Till: freeswitch-users@lists.freeswitch.org Ämne: Re: [Freeswitch-users] uuid_media hangs Thanks. Do you know in which build it was fixed? I pull from the freeswitch nightly ppa on ubuntu so will try to compile the latest snapshot and test. Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/uuid-media-hangs-tp5145657p514... Sent from the freeswitch-users mailing list archive at Nabble.com. _______________________________________________ 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 !DSPAM:4c0bf51f32932727217645!

Hmm, this seems more due to the latest snapshot having broken background events in esl. I get notification that the filter is added, but no events! If I do a straight Bridge in the dialplan things are a little different. uuid_media {uuid} waits about 5 seconds then ditches the call. A Wireshark trace shows that the reinvite is ent, the remote party then sends an RTP packet to the correct port, but fs is not ready and a Destination Unreachable ICM packet is responded, which makes the remote party clear back the call with a 420. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/uuid-media-hangs-tp5145657p514... Sent from the freeswitch-users mailing list archive at Nabble.com.

Hi Brian, I am pulling from git and do see the difference. I don't know what's going on with ESL and background events which is causing me some testing headaches but I think I know what's happening with the reinvite. The 420 that comes back seems to be moaning about the Require: timer. header that's passed by FS. The original dialogue negotiated session timers, so FS passes a header in the reinvite requiring timers. It seems that the SBC at the other end doesn't like this and in the 420 a field Unsupported: timer is included. Is there a possibility to have a configuration option which removes the Require: timer in reinvites? Cheers, Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/uuid-media-hangs-tp5145657p514... Sent from the freeswitch-users mailing list archive at Nabble.com.

On Tue, Jun 8, 2010 at 5:47 AM, peely <freeswitch@peely.com> wrote:

Hi again,

I've checked with BT, and they are unable to support reinvites with a Require: timer.

Reading the RFC, it seems that new transactions hsould not have the Require: timer but should revert to Supported: timer.

Which RFC is that? And which section?

-MC

Hi, It's not a hijacked thread, I created this with an issue around uuid_media, initially it was hanging, then in the latest git it receives a 4xx from the far end due to the Requires: timer support bot being supported in the reinvite transaction. I did anecdotally mention problems with events, which I subsequently pulled off to another thread. I was looking at RFC 4028, in the examples it shows the refresh event not providing the Required: timer header even for the refresh of the original invite transaction, just the Supported: timer. There's nothing in RFC 3725 regarding sesison timers in 3PCC but as the reinvite for the media adjustment is a new transaction, I don't think it needs the Requires: timer option to persist the timer support on the original dialogue. This is certainly the behaviour of the previous equipment I had on this interconnect and it operates using session timers and 3PCC in several other environments too. I'm not brilliant with C, but if you could please point me to the right approach to removing the Requires: timer field in the header I'd be happy to test it and let you know if it causes any problems with rienvites across various carriers and other platforms. Cheers, Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/uuid-media-hangs-tp5145657p516... Sent from the freeswitch-users mailing list archive at Nabble.com.

are very keen to actually follow all these silly RFC I agree, usually RFC are created first by university so by students...

----- Original Message ----- From: Anthony Minessale To: freeswitch-users@lists.freeswitch.org Sent: Thursday, June 10, 2010 12:09 PM Subject: Re: [Freeswitch-users] uuid_media hangs The funny part is you are willing to go to all this effort to try to make us correct it because you know the other people wont. This type of finger pointing to RFC is typical to providers so now I have to do free work to investigate it for you. And I bet you are paying them money and not us, oh well, typical.....Don't worry I won't hold it against you. The philosophical question here is weather or not to send a requires timer in the reinvite, so ok. I can try to look it up for you but from a logical point of view, once you establish in the original invite that you are going to use session timers, every reinvite constitutes a timer refresh, so once you have agreed in the original invite to use timers it would stand to reason to require the timer option in every new re-invite since it represents a timer refresh. But, let's face it... Who cares right? its a meaningless param in an REINVITE. Most sip implementation wing it on most of these packet parsers. The sofia developers are very keen to actually follow all these silly RFC you are trying to quote and they have been relaxing it nonstop ever since because nobody really follows any rules in SIP they just use them to avoid having to patch their code. Especially in a deployed appliance in a telco. They are really telling you they can't support it because the code in their sip gateway fails when it sees this and they are too lazy to change it so they pray that some RFC will let them off the hook. Trust me, we've had worse. One place refused our calls because they did not like the syntax of our user agent string...... So bottom line is I would trust the default behavior of sofia-sip over most things any day but if they are really doing something wrong the problem would be in the sofia-sip library not in FreeSWITCH so I am not sure where to tell you to look in the code to correct it because we use that code asis and avoid hacking into it a all costs. Try using grep into the sofia-sip lib for the strings you know are meaningful. P.S All the event related things are fixed now, there was a small speed bump along the way this week. On Thu, Jun 10, 2010 at 4:34 AM, peely <freeswitch@peely.com> wrote: Hi, It's not a hijacked thread, I created this with an issue around uuid_media, initially it was hanging, then in the latest git it receives a 4xx from the far end due to the Requires: timer support bot being supported in the reinvite transaction. I did anecdotally mention problems with events, which I subsequently pulled off to another thread. I was looking at RFC 4028, in the examples it shows the refresh event not providing the Required: timer header even for the refresh of the original invite transaction, just the Supported: timer. There's nothing in RFC 3725 regarding sesison timers in 3PCC but as the reinvite for the media adjustment is a new transaction, I don't think it needs the Requires: timer option to persist the timer support on the original dialogue. This is certainly the behaviour of the previous equipment I had on this interconnect and it operates using session timers and 3PCC in several other environments too. I'm not brilliant with C, but if you could please point me to the right approach to removing the Requires: timer field in the header I'd be happy to test it and let you know if it causes any problems with rienvites across various carriers and other platforms. Cheers, Neil. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/uuid-media-hangs-tp5145657p516... Sent from the freeswitch-users mailing list archive at Nabble.com. _______________________________________________ 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/ 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-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

Anyhow, thanks for the pointers and I'll take a look at Sofia and report something to them if need be. I think my first option may be to disable session timers on the test route initially, just to see if there's anything else afoot.

Question: are they even willing to look at their SIP handling? Seriously, they are bombing out a call because they don't want to ignore a header that they feel is meaningless but that others feel isn't meaningless? If everyone writing a SIP stack did something capricious like drop a call because the packet had a valid header that they just didn't want to see at that point in the dialog then SIP interop would be royal mess of voodoo programming and vendor finger pointing. It's a good thing that silly SIP implementations are rare. Oh wait... -MC P.S. - As to digging into Sofia - you are either brave or foolhardy! ;) You might want to talk to the Sofia devs directly and ask them about this exact scenario. They might be able to save you some time, or at least guide you to the right spot in the code.