----- Original message ----- > Greetings, > > We have discovered a second interop problem in our testing; this one > is less easily explainable to me in terms of SEMS mechanics, so I am > hoping some light can be shed, or it can be marked as an actual bug. > > Raphael and Stefan, I have privately e-mailed you a packet capture of > the scenario I am about to describe, but I prefer not to post it on > the public list. > > Here is the flow: > > PBX --> SEMS --> PSTN_GW > > PBX supports timer, and PSTN_GW does not. > > 1. PBX sends an initial INVITE, in which it says that it supports > timers. SEMS relays this INVITE onto PSTN_GW with Session-Expires: > 240 and Min-SE headers added. > > 2. PSTN_GW responds with 100/183/200, and no reference to timer > support in any of them. No Session-Expires header, no Supported: > timer, none of it. > > Critically, the 200 OK that is received from PSTN_GW is modified by > SEMS to contain: > > Supported: timer > Session-Expires: 240;refresher=uas > > This seems to suggest to me that SEMS has designated PSTN_GW the > refresher, even though it does not support timers! In the dialog between pbx and sems, sems is the UAS for the first invite request. So that is all ok, sems tells the pbx that sems will do the refresh.
> > 3. At 120 sec in, SEMS sends a reinvite to PBX and gets 200 OK back > that contains Session-Expires: 240;refresher=uas. This seems fishy (or I misunderstood the rfc when this was implemented): apparently the pbx tells sems that it now wants the roles swapped, that it wants to be refresher (pbx is uas in this reinvite!) > > 4. At 126 sec in, SEMS sends reinvite to PSTN_GW and gets 200 OK back > as well. Again, no indication that the PSTN_GW supports timers in any > way. > > 5. At 246 sec in, SEMS sends another reinvite to PSTN_GW, gets same > 200 OK back. > > 6. At 360 seconds, SEMS sends BYE to both endpoints. Since step #3, > there were no other reinvites to the PBX. Seems to me sems is doing everything properly: it waited for the refresh by the pbx, and when that did not come umtil session time out, it ended both legs. > > ... > > This leads me to believe that SEMS has for some reason decided that > the refreshes are going to come from PSTN_GW, and ends the call when no; on the pstngw side, it decided to be the refresher and it did the refresh properly (refresh at 126/246). In fact this looks to me like an issue in the pbx. A workaround might be to add "refresher=uac" to the reinvite sent to the pbx, in which case our beloved pbx might want to not take over the refresher role. Have a look at SessionTimer.cpp, i guess you can spot the function where to add that easily in order to try. Stefan > it does not see them after 240 seconds. Why does it do that? If that > is in fact the assumption, why send a reinvite to the PSTN_GW at all > as in step #4? > > I am unable to explain this behaviour. Any help would be appreciated! > > Cheers, > > -- > Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ > _______________________________________________ > Sems mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/sems
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
