[Spce-user] How to handle methode UPDATE

Stefan Sayer stefan.sayer at googlemail.com
Mon Oct 31 18:50:01 EDT 2011


o Andreas Granig on 10/31/2011 10:47 PM:
> Hi,
>
> On 10/31/2011 09:01 PM, Klaus Peter v. Friedeburg wrote:
>> When I configure the session-timer in sems to 600 the PSTN-Gateway give us a reply on our INVITE-Message:
>> 	422 Session Intervall too small, with Min-SE 1800
>> Then our ngcp-sems send a new INVITE with Session-Expires: 1800
>> But after exactly 600 second sems terminate the call with BYE
>> No reINVITE is sending from sems
>> The mistake is that sems don't switch the internal Session-timer to the handshaked Session-Expire: 1800

please send a debug log of such a call (per pm if you want). If the 
new INVITE is negotiated with a refresh interval of 1800, and it is 
negotiated that ngcp-sems is the refresher, it should refresh the session.

>
> Anything on the second call leg towards the client?
>
>> When I configure the session time in sems to 1800 or greater we get from the PST-Gateway after 1800 second a reINVITE, with:
>> 	Session-Expires: 1800;refresher=uac
>> The answer from sems is:
>> 	200 OK with Session-Expires: 1800;refresher=uas
>> This is not correct!! Sems must answer with the whole Text from the reINVITE in this example with
>> 	200 OK Session-Expires: 1800;refresher=uac
>
> I think I've seen this behavior before and discussed it with the Sems
> devs, but we didn't follow up on that because it was related to another
> issue.
> @Stefan, what do you think of that?

is the gateway using compact form of the Supported header (k)? I just 
fixed the support for it.

Otherwise, please let me get a debug log here as well. Of course sems 
does do it that way, and is happy to let the other side be the 
refresher (we even try to get out of the refresher role, as it's in 
our opinion better to have the refreshes end-to-end). IIRC in the case 
which Andreas is referring to, the problem was that the supported 
header was stripped.

(also, if sipwise would put the source of ngcp-sems in the repo, one 
could directly check what code is used there/apply the fix).

BR
Stefan

>
> Andreas
>

-- 
tel:+491621366449
sip:sayer at iptel.org
mailto/xmpp:stefan.sayer at gmail.com




More information about the Spce-user mailing list