[Freeswitch-users] Disabling 200 OK with contact headers of all the lines

Mon Dec 31 06:29:35 UTC 2018

Micheal,

Happy New Year !

Your thoughts on this is very much appreciated.Thanks

On Wed, Dec 19, 2018 at 1:24 PM sagar malam <sagarmalam at gmail.com> wrote:

> Thanks for information Mike.
>
> Yes,FS is doing right thing as per RFC.Also i check OpenSIPS and Kamailio
> doing same thing(i made mistake during first observation) , only difference
> is that it uses comma separated string of contacts in single contact header
> instead of separate contact headers for each registration.
>
> Looking into sofia source code, I found that FS had option to not look up
> in DB and return contact header(only one)  as it was in register packet (
> *reg-deny-binding-fetch-and-no-lookup* ).This is exactly what i was
> looking for and it solved my problem as well with polycom phones. But it is
> deprecated by FS. And not recommended by RFC.
>
> However i am curious to know what is purpose of it ? I was not able to
> find any specific reason for 200 OK to have contacts of all the bindings.Do
> you know why ?
>
> I can clearly find out below *issues* due to multiple contact headers :
> 1) Having multiple contact headers may confuse client to identify their
> own contact header and therefore may not be able to get registration expiry
> time provided by server.It happens with polycom phones for sure.(
> https://support.onsip.com/hc/en-us/articles/204028710-Polycom-Multiple-Contacts-Registration-Bug
> )
> 2) Very big SIP packets( consider a case of 20 registrations with same
> AOR).This wont be any issue while using TCP or UDP with IPv4 but if we use
> UDP with IPv6 , too big packets will be dropped by Ethernet ports because
> as per IPv6 standards only applications(FS) can fragment IPv6 UDP packets.
> 3) For each register request FS will execute query in DB to fetch all the
> registrations which adds overhead on DB as well.
>
> Looking forward for your thoughts.Thanks again.
>
> On Tue, Dec 18, 2018 at 2:05 AM Mike Jerris <mike at freeswitch.org> wrote:
>
>> https://tools.ietf.org/html/rfc3261#section-10.3
>>
>>       8. The registrar returns a 200 (OK) response.  The response MUST
>>          contain Contact header field values enumerating all current
>>          bindings.  Each Contact value MUST feature an "expires"
>>          parameter indicating its expiration interval chosen by the
>>          registrar.  The response SHOULD include a Date header field.
>>
>>
>>
>> On Dec 17, 2018, at 9:13 AM, sagar malam <sagarmalam at gmail.com> wrote:
>>
>> Thanks for reply Micheal.
>>
>> I dont want to disable multiple registrations.And i agree all the
>> registrations are genuine.
>>
>> But my problem is that when FS responds to Register Request using 200 OK,
>> The 200 OK has contact headers of all the registrations( of other SIP
>> clients).As shown in below packet, there are three contact headers.I think
>> there should be only one.
>>
>> ============================200 OK for register packet =============
>>
>> 2018/12/08 13:36:35.426099 10.50.7.251:5070 -> 10.50.7.253:5060
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 66.160.237.253:5060
>> ;branch=z9hG4bK9b46.f9b7a68125108f411537617d02bd48f8.0;received=10.50.7.253
>> Via: SIP/2.0/UDP 198.136.236.1:5060
>> ;rport=5060;received=10.50.8.1;branch=z9hG4bK9b46.e6f1aa3817a238f499aa3aafa4217425.0
>> Via: SIP/2.0/UDP
>> 172.16.1.11;rport=1426;received=71.239.113.14;branch=z9hG4bK1df2302cD062D28F
>> From: "Main Line" <sip:398 at example.com>;tag=22CE54C0-84BCCF23
>> To: <sip:398 at example.com>;tag=e8Fa2tND4U80D
>> Call-ID: d66f0f0592c09746b903406f312eb0c2
>> CSeq: 590 REGISTER
>> *Contact:
>> <sip:398 at 71.239.113.14:1071;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.12;pb-ip=71.239.113.14;pb-pt=1071;mac-address=64167f2ec274;transp*
>> *t=tcp>;expires=379*
>> *Contact:
>> <sip:398 at 71.239.113.14:56478;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.13;pb-ip=71.239.113.14;pb-pt=56478;mac-address=64167f2ebd54;tran*
>> *ort=tcp>;expires=245*
>> *Contact:
>> <sip:398 at 71.239.113.14:1426;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.11;pb-ip=71.239.113.14;pb-pt=1426;transport=udp;mac-address=64167*
>> *eb0c2>;expires=88*
>> Date: Sat, 08 Dec 2018 08:06:35 GMT
>> User-Agent: FreeSWITCH-mod_sofia/1.6.17~64bit
>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>> Supported: path, replaces
>> Content-Length: 0
>>
>> ===========================================================
>>
>> Also i have compared this behaviour with OpenSIPs and Kamailio, They send
>> only one contact header.
>>
>> Thanks in advance.
>>
>>
>>
>> On Wed, Dec 12, 2018 at 3:08 AM Michael Jerris <mike at jerris.com> wrote:
>>
>>> These are all valid current registrations, there are params you can
>>> adjust for multi reg that will replace previous registrations instead of
>>> allowing multiple.
>>>
>>> On Dec 9, 2018, at 1:17 PM, sagar malam <sagarmalam at gmail.com> wrote:
>>>
>>> Hello ,
>>>
>>> I am using FS SLA feature and it works very well.However i am facing an
>>> issue of registrations getting dropped as explained below :
>>> There are 3 phones registered with same extension number.Sofia is
>>> configured with "sip-expires-max-deviation" to randomise registration
>>> through expiry header in contact header.All the phones are Polycom. In case
>>> of shared lines FS adds contact header of all the lines(or phones with same
>>> extension) in 200 OK as shown below due to which all the phones are reading
>>> expiry timer from first contact header only.So in below example,Phone re
>>> registers after 379 seconds(first contact header) instead of 88
>>> seconds(third contact header) leading to registration expiry on FS.
>>>
>>> Reason why phones are always reading expiry from first contact header is
>>> same Public IP(contact is re written by Proxy in front of FS)  for all
>>> three phones which is confusing phone to identify its own contact header.
>>> Is there any way to configure FS to not send contact headers of all the
>>> registrations but only one that belongs to the line itself ? or any other
>>> way to fix it.
>>> ============================200 OK for register packet =============
>>>
>>> 2018/12/08 13:36:35.426099 10.50.7.251:5070 -> 10.50.7.253:5060
>>> SIP/2.0 200 OK
>>> Via: SIP/2.0/UDP 66.160.237.253:5060
>>> ;branch=z9hG4bK9b46.f9b7a68125108f411537617d02bd48f8.0;received=10.50.7.253
>>> Via: SIP/2.0/UDP 198.136.236.1:5060
>>> ;rport=5060;received=10.50.8.1;branch=z9hG4bK9b46.e6f1aa3817a238f499aa3aafa4217425.0
>>> Via: SIP/2.0/UDP
>>> 172.16.1.11;rport=1426;received=71.239.113.14;branch=z9hG4bK1df2302cD062D28F
>>> From: "Main Line" <sip:398 at example.com>;tag=22CE54C0-84BCCF23
>>> To: <sip:398 at example.com>;tag=e8Fa2tND4U80D
>>> Call-ID: d66f0f0592c09746b903406f312eb0c2
>>> CSeq: 590 REGISTER
>>> Contact: <
>>> sip:398 at 71.239.113.14:1071;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.12;pb-ip=71.239.113.14;pb-pt=1071;mac-address=64167f2ec274;transp
>>> t=tcp>;expires=379
>>> Contact: <
>>> sip:398 at 71.239.113.14:56478;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.13;pb-ip=71.239.113.14;pb-pt=56478;mac-address=64167f2ebd54;tran
>>> ort=tcp>;expires=245
>>> Contact: <
>>> sip:398 at 71.239.113.14:1426;alias=10.50.8.1~5060~1;x-nat=yes;pv-ip=172.16.1.11;pb-ip=71.239.113.14;pb-pt=1426;transport=udp;mac-address=64167
>>> eb0c2>;expires=88
>>> Date: Sat, 08 Dec 2018 08:06:35 GMT
>>> User-Agent: FreeSWITCH-mod_sofia/1.6.17~64bit
>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>> Supported: path, replaces
>>> Content-Length: 0
>>>
>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Services
>> sales at freeswitch.com
>> https://freeswitch.com
>>
>> Official FreeSWITCH Sites
>> https://freeswitch.com/oss
>> https://freeswitch.org/confluence
>> https://cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> https://freeswitch.com
>
>
>
> --
> Thanks,
>
> Sagar
>

-- 
Thanks,

Sagar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20181231/1e965fab/attachment-0001.html>