<div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks for information Mike.<div><br></div><div>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.</div><div><br></div><div>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 ( <b>reg-deny-binding-fetch-and-no-lookup</b> ).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. </div><div><br></div><div>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 ?</div><div><br></div><div>I can clearly find out below <b>issues</b> due to multiple contact headers : </div><div>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.(<a href="https://support.onsip.com/hc/en-us/articles/204028710-Polycom-Multiple-Contacts-Registration-Bug" target="_blank">https://support.onsip.com/hc/en-us/articles/204028710-Polycom-Multiple-Contacts-Registration-Bug</a>)</div><div>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.</div><div>3) For each register request FS will execute query in DB to fetch all the registrations which adds overhead on DB as well.</div><div><br></div><div>Looking forward for your thoughts.Thanks again.</div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 2:05 AM Mike Jerris <<a href="mailto:mike@freeswitch.org" target="_blank">mike@freeswitch.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><a href="https://tools.ietf.org/html/rfc3261#section-10.3" target="_blank">https://tools.ietf.org/html/rfc3261#section-10.3</a><div><br></div><div><pre class="gmail-m_-1903184527135754702gmail-m_-7549818843252830095gmail-m_-7049652788308635096newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;font-variant-ligatures:normal"> 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.
</pre><div><br><blockquote type="cite"><div>On Dec 17, 2018, at 9:13 AM, sagar malam <<a href="mailto:sagarmalam@gmail.com" target="_blank">sagarmalam@gmail.com</a>> wrote:</div><br class="gmail-m_-1903184527135754702gmail-m_-7549818843252830095gmail-m_-7049652788308635096Apple-interchange-newline"><div><div dir="ltr">Thanks for reply Micheal.<div><br></div><div>I dont want to disable multiple registrations.And i agree all the registrations are genuine.</div><div><br></div><div>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. </div><div><br></div><div><div>============================200 OK for register packet =============</div><div><br></div><div><div>2018/12/08 13:36:35.426099 <a href="http://10.50.7.251:5070/" target="_blank">10.50.7.251:5070</a> -> <a href="http://10.50.7.253:5060/" target="_blank">10.50.7.253:5060</a></div><div>SIP/2.0 200 OK</div><div>Via: SIP/2.0/UDP 66.160.237.253:5060;branch=z9hG4bK9b46.f9b7a68125108f411537617d02bd48f8.0;received=10.50.7.253</div><div>Via: SIP/2.0/UDP 198.136.236.1:5060;rport=5060;received=10.50.8.1;branch=z9hG4bK9b46.e6f1aa3817a238f499aa3aafa4217425.0</div><div>Via: SIP/2.0/UDP 172.16.1.11;rport=1426;received=71.239.113.14;branch=z9hG4bK1df2302cD062D28F</div><div>From: "Main Line" <<a href="mailto:sip%3A398@example.com" target="_blank">sip:398@example.com</a>>;tag=22CE54C0-84BCCF23</div><div>To: <<a href="mailto:sip%3A398@example.com" target="_blank">sip:398@example.com</a>>;tag=e8Fa2tND4U80D</div><div>Call-ID: d66f0f0592c09746b903406f312eb0c2</div><div>CSeq: 590 REGISTER</div><div><b>Contact: <<a>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</a></b></div><div><b>t=tcp>;expires=379</b></div><div><b>Contact: <<a>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</a></b></div><div><b>ort=tcp>;expires=245</b></div><div><b>Contact: <<a>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</a></b></div><div><b>eb0c2>;expires=88</b></div><div>Date: Sat, 08 Dec 2018 08:06:35 GMT</div><div>User-Agent: FreeSWITCH-mod_sofia/1.6.17~64bit</div><div>Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE</div><div>Supported: path, replaces</div><div>Content-Length: 0</div><div><br></div><div>===========================================================</div></div></div><div><br></div><div>Also i have compared this behaviour with OpenSIPs and Kamailio, They send only one contact header.</div><div><br></div><div>Thanks in advance.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 3:08 AM Michael Jerris <<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>These are all valid current registrations, there are params you can adjust for multi reg that will replace previous registrations instead of allowing multiple.<br><div><br><blockquote type="cite"><div>On Dec 9, 2018, at 1:17 PM, sagar malam <<a href="mailto:sagarmalam@gmail.com" target="_blank">sagarmalam@gmail.com</a>> wrote:</div><br class="gmail-m_-1903184527135754702gmail-m_-7549818843252830095gmail-m_-7049652788308635096gmail-m_-6478108143715557220Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello ,<div><br></div><div>I am using FS SLA feature and it works very well.However i am facing an issue of registrations getting dropped as explained below : </div><div>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.</div><div><br></div><div>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.</div><div>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. </div><div>============================200 OK for register packet =============</div><div><br></div><div><div>2018/12/08 13:36:35.426099 <a href="http://10.50.7.251:5070/" target="_blank">10.50.7.251:5070</a> -> <a href="http://10.50.7.253:5060/" target="_blank">10.50.7.253:5060</a></div><div>SIP/2.0 200 OK</div><div>Via: SIP/2.0/UDP 66.160.237.253:5060;branch=z9hG4bK9b46.f9b7a68125108f411537617d02bd48f8.0;received=10.50.7.253</div><div>Via: SIP/2.0/UDP 198.136.236.1:5060;rport=5060;received=10.50.8.1;branch=z9hG4bK9b46.e6f1aa3817a238f499aa3aafa4217425.0</div><div>Via: SIP/2.0/UDP 172.16.1.11;rport=1426;received=71.239.113.14;branch=z9hG4bK1df2302cD062D28F</div><div>From: "Main Line" <<a href="mailto:sip%3A398@example.com" target="_blank">sip:398@example.com</a>>;tag=22CE54C0-84BCCF23</div><div>To: <<a href="mailto:sip%3A398@example.com" target="_blank">sip:398@example.com</a>>;tag=e8Fa2tND4U80D</div><div>Call-ID: d66f0f0592c09746b903406f312eb0c2</div><div>CSeq: 590 REGISTER</div><div>Contact: <<a>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</a></div><div>t=tcp>;expires=379</div><div>Contact: <<a>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</a></div><div>ort=tcp>;expires=245</div><div>Contact: <<a>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</a></div><div>eb0c2>;expires=88</div><div>Date: Sat, 08 Dec 2018 08:06:35 GMT</div><div>User-Agent: FreeSWITCH-mod_sofia/1.6.17~64bit</div><div>Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE</div><div>Supported: path, replaces</div><div>Content-Length: 0</div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div><br></div></div>_________________________________________________________________________<br>
Professional FreeSWITCH Services<br>
<a href="mailto:sales@freeswitch.com" target="_blank">sales@freeswitch.com</a><br>
<a href="https://freeswitch.com" rel="noreferrer" target="_blank">https://freeswitch.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="https://freeswitch.com/oss" rel="noreferrer" target="_blank">https://freeswitch.com/oss</a><br>
<a href="https://freeswitch.org/confluence" rel="noreferrer" target="_blank">https://freeswitch.org/confluence</a><br>
<a href="https://cluecon.com" rel="noreferrer" target="_blank">https://cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="https://freeswitch.com" rel="noreferrer" target="_blank">https://freeswitch.com</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-1903184527135754702gmail-m_-7549818843252830095gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Sagar</div></div></div></div></div></div></div>