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

Wed Dec 19 07:54:14 UTC 2018

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20181219/d37c7613/attachment-0001.html>