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-Conta... ) 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@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@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@example.com>;tag=22CE54C0-84BCCF23 To: <sip:398@example.com>;tag=e8Fa2tND4U80D Call-ID: d66f0f0592c09746b903406f312eb0c2 CSeq: 590 REGISTER *Contact: <sip:398@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@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@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@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@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@example.com>;tag=22CE54C0-84BCCF23 To: <sip:398@example.com>;tag=e8Fa2tND4U80D Call-ID: d66f0f0592c09746b903406f312eb0c2 CSeq: 590 REGISTER Contact: < sip:398@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@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@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@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@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