[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
<BR><FONT SIZE=3D2>meaning in INVITE, and another in re-INVITE. This =
makes defining policies</FONT>
<BR><FONT SIZE=3D2>based on the From field more complex, since they no =
longer work properly for</FONT>
<BR><FONT SIZE=3D2>re-INVITE. </FONT>
</P>
<P><FONT SIZE=3D2>2. call-leg ID lookups in gateways are much faster =
now, since the tags and</FONT>
<BR><FONT SIZE=3D2>call-ids are just strings. Matching is now =
case-sensitive string compares.</FONT>
<BR><FONT SIZE=3D2>Much easier than URL comparison. </FONT>
</P>
<P><FONT SIZE=3D2>3. Overlap dialing is easier. The reason we've had to =
send each digit as a</FONT>
<BR><FONT SIZE=3D2>new call leg, is that we needed to change the To =
field and the request URI.</FONT>
<BR><FONT SIZE=3D2>By definition, this meant a new call leg. Now, we can =
send all of that</FONT>
<BR><FONT SIZE=3D2>within a single call leg. Much cleaner.</FONT>
</P>
<P><FONT SIZE=3D2>4. The Replaces draft benefits. We've already =
identified a need for the</FONT>
<BR><FONT SIZE=3D2>Replaces header to identify the entire call leg thats =
being replaced. This</FONT>
<BR><FONT SIZE=3D2>gets big when it carries two URLs, two tags, and a =
call-id. Now, we can</FONT>
<BR><FONT SIZE=3D2>throw away the URLs. This shortens the header and =
makes matching of the</FONT>
<BR><FONT SIZE=3D2>call-leg IDs easier.</FONT>
</P>
<P><FONT SIZE=3D2>5. It works with existing proxies.</FONT>
</P>
<P><FONT SIZE=3D2>THe main drawback, of course, is that this won't =
interoperate with rfc2543</FONT>
<BR><FONT SIZE=3D2>UAs. Thats fixable with Supported; the UAC indicates =
Supported:</FONT>
<BR><FONT SIZE=3D2>new-call-leg-id in the INVITE if it understands this. =
In that case, any</FONT>
<BR><FONT SIZE=3D2>responses or re-invites that change the URLs include =
a Require:</FONT>
<BR><FONT SIZE=3D2>new-call-leg-id. </FONT>
</P>
<P><FONT SIZE=3D2>I fully admit that this may not be worth the pain. =
However, I'd welcome</FONT>
<BR><FONT SIZE=3D2>comments from others on whether its useful to =
consider further.</FONT>
</P>
<P><FONT SIZE=3D2>-Jonathan R.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>---</FONT>
<BR><FONT SIZE=3D2>Jonathan D. Rosenberg, =
Ph.D. &n=
bsp; 72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=3D2>Chief =
Scientist &nbs=
p;  =
; First Floor</FONT>
<BR><FONT =
SIZE=3D2>dynamicsoft  =
; =
East =
Hanover, NJ 07936</FONT>
<BR><FONT =
SIZE=3D2>jdrosen@dynamicsoft.com  =
; =
FAX: (973) 952-5050</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.jdrosen.net">http://www.jdrosen.net</A> &nb=
sp; &nbs=
p; PHONE: (973) 952-5000</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.dynamicsoft.com">http://www.dynamicsoft.com</A></FONT>=
<BR><FONT SIZE=3D2> </FONT>
</P>
<P><FONT SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Sip mailing list <A =
HREF=3D"http://www.ietf.org/mailman/listinfo/sip">http://www.ietf.org/mai=
lman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>
<BR><FONT SIZE=3D2>Use sip-implementors@cs.columbia.edu for questions on =
current sip</FONT>
<BR><FONT SIZE=3D2>Use sipping@ietf.org for new developments on the =
application of sip</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C10A27.14D863D4--
_______________________________________________
Sip mailing list http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip