Re: [Sip] 199: Staus and open issues after Dublin

["Brett Tate" <brett at broadsoft.com>]

> We will not define an option-tag for 199 support. 

Since the working group has issue with using option-tag, I propose
something else be added to request to indicate that something along the
path supports and desires receiving 199.

For instance, rfc4028 allows the UAC or proxy to include
Session-Expires.  A similar header (maybe generic one) could be defined
and optionally contain parameters (uac, proxy, etcetera); for instance,
"Desire-199:".


> 1) Is a proxy allowed to send 199 in the first 
> place, or are only UASes allowed to do it?

I have no issue with allowing it.  However the draft should likely
provide guidance if originator of 199 still considered a proxy or has
morphed into UAS/b2bua when using another's To tag.  Depending upon
interpretation of rfc3261 (and dropped packets), there are potential
issues concerning Contact and Record-Route of the 199 (unless remember
prior for inclusion within 199).  

What should occur when INVITE 2xx received after proxy originated 199
with the same To tag?


> 2) are proxies allowed to send 199 reliably?

I wouldn't consider it a proxy since it is trampling upon another's RSeq
and dialog (depending upon 199's Record-Route and Contact).


> 3) Assuming proxies are allowed to send 199 (see 
> issue 1), are proxies allowed to send 199 
> unreliably, even if 100rel is required? 

Concerning this and other non compliances, not sending the 199 would
likely be best to avoid violating rfc3261/rfc3262.


> 4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199? 

I prefer MAY.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip