[SR-Users] Phone does not set "Expire-header" but "Contact expire", immediately expires

Kevin Olbrich ko at sv01.de
Tue Nov 6 22:50:54 CET 2018


Am Di., 6. Nov. 2018 um 22:40 Uhr schrieb Sergiu Pojoga <pojogas at gmail.com>:

> It's not clear what kamailio/asterisk integration method you are using.
> Looking at the 2 provided messages - the 2nd one is not a relay of the 1st
> one.
>

I might have matched the wrong transaction. I use HEP/HOMER to observe
communication and Kamailio starts a new flow (=Call-Id) to asterisk (this
message is no coming from the phone).


> handle authentication/usrloc in Kamailio?
> or
> using PATH extension?
>

I do auth + usrloc in Kamailio, no PATH.

Maybe the Kamailio debug would lead me to the problem but verbose level 3
has too much info.

Kevin


> Cheers.
>
> On Tue, Nov 6, 2018 at 4:00 PM Kevin Olbrich <ko at sv01.de> wrote:
>
>> Hi!
>>
>> I have a phone (Mitel 6930) that does not send an Expire-header but
>> "expire" in Contact during REGISTER:
>>
>> Session Initiation Protocol (REGISTER)
>>>     Request-Line: REGISTER sip:pbx.example.com SIP/2.0
>>>     Message Header
>>>         Via: SIP/2.0/TLS 192.168.6.16:5061;branch=xxxxxxxxxxxxxxxx;rport
>>>         Route: <sip:pbx.example.com;lr=lr;transport=tls>
>>>         Max-Forwards: 70
>>>         From: "Example" <sip:121212_6666 at pbx.example.com>;tag=b0cec92c3e
>>>         To: "Example" <sip:121212_6666 at pbx.example.com>
>>>         Call-ID: aaaaaaaaaaaaaaaaa
>>>         CSeq: 1190442896 REGISTER
>>>         Accept-Language: de
>>>         Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE,
>>> PRACK, SUBSCRIBE, INFO, PUBLISH
>>>         Allow-Events: talk, hold, conference, LocalModeStatus
>>>         Contact: "Example" <sip:121212_6666 at 192.0.2.1:62336
>>> >;+sip.instance="<urn:uuid:00000000-0000-1000-8000-08000FB888F5>";expires=300
>>>         Supported: path, gruu
>>>         User-Agent: Mitel 6930/5.0.0.2041
>>>         Aastra-Line: 1
>>>         Aastra-Mac: AAAAAAAAAAAA
>>>         Content-Length: 0
>>
>>
>> This results in successful register, kamailio forwards REGISTER to
>> asterisk (endpoint registered) and immediatly kamailio sends a new REGISTER
>> with Expire set to 0 to asterisk:
>>
>> Session Initiation Protocol (REGISTER)
>>>     Request-Line: REGISTER sip:192.168.99.112:5060 SIP/2.0
>>>     Message Header
>>>         Via: SIP/2.0/UDP 192.168.99.111:5060
>>> ;branch=z9hG4bK9f9e.599cf243000000000000000000000000.0
>>>         To: <sip:121212_6666 at 192.168.99.112>
>>>         From: <sip:121212_6666 at 192.168.99.112
>>> >;tag=7e4f6993bfbf831f6b016fea6683cdca-b98a
>>>         CSeq: 10 REGISTER
>>>         Call-ID: 2bc5fd1061b31723-1350 at 192.168.99.111
>>>         Max-Forwards: 70
>>>         Content-Length: 0
>>>         User-Agent: kamailio (5.1.6 (x86_64/linux))
>>>         Contact: <sip:121212_6666 at 192.168.99.111:5060>
>>>         Expires: 0
>>
>>
>> The phone is then unregistered - the phone also shows "no service". It
>> looks like Kamailio generates this message on it's own (and I don't know
>> why).
>>
>> I am still learning to implement kamailio as proxy. Reading the docs, I
>> would expect Kamailio to automatically eval the correct parameter:
>>
>>> If the processed message contains neither Expires HFs nor expires
>>> contact parameters, this value will be used for newly created usrloc
>>> records.
>>
>> [1]
>>
>> What did I miss?
>> Phones which use the Expire-header are working fine.
>>
>> Kind regards
>> Kevin
>>
>> [1] default_expires -
>> http://www.kamailio.org/docs/modules/5.2.x/modules/registrar.html
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181106/7e14abfe/attachment.html>


More information about the sr-users mailing list