<div dir="ltr"><br><br><div class="gmail_quote">2008/10/2 SIP <span dir="ltr"><<a href="mailto:sip@arcdiv.com">sip@arcdiv.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">Olivier wrote:<br>
> Hi,<br>
><br>
> I've seen some hardphones or Softswitchs now support this sip.instance<br>
> feature :<br>
> <a href="http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance-id-01.txt" target="_blank">http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance-id-01.txt</a><br>
><br>
> I don't really see any convincing use of this draft but I would be<br>
> curious to share thoughts on it.<br>
><br>
> Cheers<br>
><br>
</div></div>> ------------------------------------------------------------------------<br>
We see similar things a lot from X-Lite (although their implementation<br>
is somewhat different and has, in the past, been broken) -- using<br>
rinstance or some such. The IDEA is sound to a point. It's useful to be<br>
able to have an identifier with the UA to determine which UA is which<br>
for purposes of differentiation if people are logging in multiple times<br>
with the same username (something Asterisk doesn't allow).<br>
<br>
It's usually handled with simple registration parameters using IP/port<br>
combinations as differentiators, but if you're running a symmetric NAT,<br>
that may be misleading or even non-functional. The instance COULD act as<br>
an additional identifier to help clarify those situations on the SIP<br>
side (as opposed to just the RTP side).<br>
<br>
I do NOT, however, feel that such an identifier need last through<br>
reboots or even be semi-permanent in any way. It's logically nice to<br>
have a separation of instances of the same IP's clients (some of our<br>
users log in multiple times from multiple machines from the same IP) for<br>
programmatic purposes perhaps, but on a reboot, a new mapping should and<br>
would be sent via the REGISTER request, and so keeping this data across<br>
UA reboots seems.... unnecessary. And likely a security risk.<br>
<br>
Where are you seeing this crop up?</blockquote><div> </div><div>I've seen it in Thomson ST2030 hardphones naming compliance with Sylantro software. <br>I read the mentioned draft RFC and wondered what it be useful for ?<br>
<br>If an hardphone has a SIP ID valued to its MAC address, it could remain valid between reboots though I don't think the sip.instance's goal is just to provide that ...<br>Maybe it's more relevant during other period of endpoint's liflecycle : before a phone is configured with a stable ID ...<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<br>
N.<br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
AstriCon 2008 - September 22 - 25 Phoenix, Arizona<br>
Register Now: <a href="http://www.astricon.net" target="_blank">http://www.astricon.net</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br></div>